When I boot into `PERSISTENT Mode | SYSMAINT Session | system maintenance tasks` the System Maintenance Panel never appears. Why is this? Is there a way to manually open once I am in it with a keybind or something? I rebooted the system and that didn’t fix it either.
Could you share a screenshot of the issue (or a photo of the screen if this is on a physical computer)? This shouldn’t be possible with Kicksecure 18 with the default desktop environment due to how the desktop background is displayed, but it could occur on Kicksecure 17 and might occur if you’re using X11. A screenshot will give me some visual clues as to which one you’re using, especially if it includes the panel/bar at the top of the screen.
The ISO I downloaded is `Kicksecure-LXQt-18.1.4.2.Intel_AMD64` and the top bar looks identical to the screenshot on the Wiki.
wiki/System_Maintenance_Panel (Can’t post links)
The background is also the same but there is no pop-up. It’s on a separate laptop but I could get a picture if these clues don’t help you.
If it has the bright yellow background behind the “Volume” indicator, you’re using Wayland, not X11, which is a good thing.
A couple more ideas:
- If you press Alt+Tab, does the window show up?
- If you press Ctrl+Alt+T, then run
sysmaint-panel, do any errors appear?
Ahh, was wondering the command to pull up the panel, that did it for me!
No errors, just doesn’t appear automatically, no big deal though.
Thanks so much for your help @arraybolt3 !
Glad to hear it worked! I’m still a bit worried to hear that it doesn’t appear automatically (it’s supposed to, and on my end it does), I’ll see if I can make the same issue happen using the ISO you used.
Edit: Just tested in a virtual machine, can’t reproduce the issue here.
It might’ve been an alt-tab issue, will reboot and see if I can alt-tab to view it.
Edit: Can confirm, all I had to do was alt-tab. It was popped up just not in the foreground.
Actually, I have the same issue and I can reproduce. Looking at the Python source code, sysmaint-panel tries to emulate background using windows if WAYLAND_DISPLAY is not set. This is normally set by labwc during its startup.
A quick glance at /usr/libexec/user-sysmaint-split/sysmaint-session-wayland show that there’s a light_sleep 3 line. This means if labwc didn’t fully start in 3 seconds, sysmaint-panel will start anyway and it won’t have WAYLAND_DISPLAY. Hence the symptoms. Changing that line to light_sleep 6 makes that problem go away for me. (This isn’t a proper fix – just to debug.)
Based on the comments above that line, it’s only reproducible with physical graphics hardware. And I guess some systems are slower than others, and I bet some monitors are slower to react than others too. If you remove the light_sleep or change it to 1 maybe you can get it to reproduce on a VM.
However, this makes me wanting a better solution than sleeping. Maybe poll systemctl --user show-environment | grep WAYLAND_DISPLAY each second will do the trick. If WAYLAND_DISPLAY is set, the panel can immediately start and will behave much better. If not, maybe start it anyway after, say, 10 polls (10 seconds).
FYI, this is on Line 154 on my end. I really want to link to the exact line and commit with a GitHub permalink but my account is new so the system probably won’t let me.
The issue there is that labwc doesn’t set an environment variable in systemd itself, so it’s somewhat tricky to know when it’s set up. Maybe though we can accurately predict what Wayland socket name it will use and immediately set that in systemd.
I’ve got an idea. I’ll try it and report back but posting here FYI.
labwc documentation says that the autostart file is executed after labwc has read its configuration and WAYLAND_DISPLAY will be defined. I think this is the perfect place to start GUI apps like sysmaint-panel. So I’m gonna try moving the second part of sysmaint-session-wayland into /usr/share/desktop-config-dist/labwc/autostart (wrapping it inside if [ $USER = sysmaint ]) and see what happens. This may take a while due to the refactor.
On the other hand, this gave me a much simpler idea:
If I just add touch $XDG_RUNTIME_DIR/labwc-ready into /usr/share/desktop-config-dist/labwc/autostart then any script can test if labwc is "ready” in the sense that it has gone pretty far. I’ll poll that instead of light_sleep in sysmaint-session-wayland. This way the changes should be minimal.
Time to mess with distro files and see what happens ![]()
This reminds me that labwc has a “startup command” feature, which I think LXQt uses under the hood to dodge this. Maybe that could be used…
Oh I feel so dumb. I should have RTFM’d. See what I’ve found in man labwc
-S, --session <command>
Run command on startup and terminate compositor on exit. This is useful for session management as it allows the session client to terminate labwc by exiting itself. This is a Wayland specific [...]
So it really just takes one line (3 to be extensible but still)
if [ "${selected_window_manager}" = '/usr/bin/labwc' ]; then
exec "${selected_window_manager}" ${selected_window_manager_args} --session "${selected_sysmaint_app}"
fi
And that replaces almost everything below. The light_sleep timing, parsing systemctl --user show-environment, and waiting for sysmaint-panel to exit. All unnecessary unless we support another WM. No need to change another file either.
The only thing is that --session <command> doesn’t seem to like shell syntax. So the above solution won’t start waybar. But that can be solved by moving waybar to /usr/share/desktop-config-dist/labwc/autostart. Or just creating a wrapper script for waybar & sysmaint-panel. Okay, a bit more complicated than that if we want it extensible to other tray apps later.
I’m quite happy with my solution on my box so far.
Hey folks a little late here but I too want to report that after I did an upgrade about a few days ago I am encountering the same issue with sysmaint panel disappearing. Not only is sysmaint panel missing in sysmaint mode but also is the system panel tray at the top that display the WiFi, Battery Level, and Time. When I did ctrl+alt+T or for better words popped a shell so to speak then the system tray panel appears but still no sysmaint panel.
It only appears when I manual type in the sysmaint-panel command. Then when I close all terminals or the terminal both the system panel tray and sysmaint disappear again.
Here is what sysmaint-panel output was if it helps:
[sysmaint ~]% sysmaint-panel
2026-04-24 04:04:05 - [main.c:282] Found config * for output eDP-1 (Samsung Display Corp. 0x5441)
My question is what changed in the latest update that broke this?
Unlikely to have been caused by an update, the code that handles launching the system maintenance panel, background image, and Waybar haven’t changed much. If you can reliably reproduce the issue with one version of sysmaint-panel, but not with an earlier version, it would help to know the working and broken versions. If reproduction requires special steps, those would be useful too.
All I know is the issue appeared after I tried to install “Dangerzone” (failed) and then did full upgrade in sysmaint session. I can try to backtrack my history but that is what I last did before it happened.