The static systemd user service for wlr-resize-watcher does not restart when the LxQT session is logged out. It keeps running instead, but does not attach to the new session. Running loginctl terminate-user user instead works as intended, so it is probably a LXQt bug not to close the systemd session properly.
Whonix version
Whonix 18 variants KVM and Virtualbox were tested. Other graphical variants might be affected.
Affected components
Whonix-Workstation with LXQt. Gateway might be affected, if dynamic resolution is disabled.
Steps to reproduce
(Virtualbox only) Set the machine view to scaled. Otherwise no resolution change might be triggered.
Boot a user session, because LXQt logout is not possible within sysmaint.
Login to the initial user session via autologin or user/password.
Logout via LXQt menu dialog.
Relogin.
Actual Results
The resolution will resize unexpectedly afer relogin.
ps aux | grep wlr-resize-watcher as well as systemctl --user status wlr-resize-watcher indicate the service being running.
The running instance does not prevent resolution changes, because it is attached to the wrong session.
Expected Results
A new instance of wlr-resize-watcher should run and attache to the new session, when greetd spawns a new one.
Context
Relogin, for instance to update environment variables triggers this bug for users in regular use.
Workaround
A temporary workaround for the LXQt bug not closing the systemd session properly is to create a desktop file in /etc/xdg/autostart. The downside is, that it can be disabled by the user. On the other hand the user already has permissions to stop it, so this should be of minor concern.
#/etc/xdg/autostart/wlr-resize-watcher.desktop
[Desktop Entry]
Name=Wlr Resize Watcher
Comment=Watches for and prevents resolution changes.
Type=Application
Terminal=false
## Hardcoded "sleep 3". Otherwise the desktop environment is not fully initialized,
## which results in the window being slightly outside the visible area.
Exec=bash -c "sleep 3 && /usr/bin/wlr-resize-watcher"
Result:
The user service will fail to start with the current setup, but the resize-watcher runs reliably.
Cannot reproduce on my end, running Whonix-Workstation-LXQt on VirtualBox 7.2.6 on a Kubuntu 24.04 host. The “actual behavior” does not occur, and if I log out of the user session in the workstation, then switch to a TTY, log in, and run pgrep wlr-resize-wat, no running processes are shown.
wlr-resize-watcher does not “attach” to a running Wayland compositor, it reads info from the compositor and sends commands to it using wlr-randr, which briefly connects, does what it needs to do, and then exits. It shouldn’t matter if wlr-resize-watcher continues running through a login/logout cycle rather than being restarted, since wlr-randr should pick up the new compositor automatically. (It might be possible for the watcher to crash if it tries to interface with the running compositor while there is no running compositor, but that’s not the problem described here.)
Cannot reproduce on my end, running Whonix-Workstation-LXQt on VirtualBox 7.2.6 on a Kubuntu 24.04 host. The “actual behavior” does not occur, and if I log out of the user session in the workstation, then switch to a TTY, log in, and run pgrep wlr-resize-wat, no running processes are shown.
If you switch to a TTY instead of doing a relogin with greetd you are not using the default configuration. A login from TTY creates a new systemd session. In that session the wlr-resize-watcher user service will successfully start, because systemd considers it as not being started in that session context yet. If you logout via LXQt and let a dm like greetd handle it, the session might not fully close. I’m actually not certain, whether greetd or LXQt is to blame here, but on the other hand, the behavior to retain certain services may be desired in some use cases.
Other reproduction hindrances include:
You run Virtualbox in fullscreen and your host resolution is 1920x1080. Then wlr-resize-watcher will have no effect whatsoever.
You did not change from the default Virtualbox view to scaled view. If you see scroll bars in the Virtualbox Machine window you are using the default view (remind you of step 1).
pgrep does not check the full commandline by default and wlr-resize-watcher is a python script. Use pgrep -f wlr-resize-watcher to find it. If you enabled dynamic resolution in /etc/wlr-resize-watcher.d/45_* it will also not run.
Yes, it uses dbus ipc to connect to the compositor api, but that is not available anymore in the session it is running on after a logout. The DBUS_SESSION_BUS_ADDRESS becomes invalid, because the environment changes and wlr-resize-watcher still runs within the old one. That is the issue. And it explains why it affects all vm types.
I’ve also found an existing desktop file, which I unfortunately did overlook before the bug report. It is the reason, why the user service has no install section. The solution is to change /etc/xdg/autostart/wlr-resize-watcher.desktop like this:
(For clarification here, I am the original author of wlr-resize-watcher.)
No, it does not. It temporarily connects to the compositor with wlr-randr when necessary. wlr-randr connects to whatever compositor the user happens to be running via a UNIX socket at /run/user/UID/wayland-* as far as I can tell (I checked the source code for it and it doesn’t mention dbus in the files I checked). If there is documentation that is saying that D-Bus is being used, or that wlr-resize-watcher is attaching persistently, or similar, please link to it, it probably needs to be edited to correct that. If this doesn’t come from documentation, whatever source you’re getting this from should probably be distrusted by default (whether that’s a forum, a YouTube video, or an AI chatbot).
I’m still not quite clear on what the unexpected behavior is:
I don’t see this, regardless of whether I’m using scaled mode or normal mode. I do see on the initial login that the screen flashes after initial bootup, but this is most likely because wlr-resize-watcher is setting the display to a 1920x1080 resolution, which it is designed to do by default on Whonix-Workstation for privacy reasons.
This is expected if you have an active graphical login. It’s unexpected but should be benign otherwise.
If dynamic resolution is enabled, resolution changes on resize are expected. If dynamic resolution is disabled, then resolution changes on resize are unexpected, but that should be impossible. I suspect this isn’t the behavior you’re experiencing though.
FWIW, I tried both scaled and non-scaled views, and wasn’t able to produce buggy behavior with either one. My machine’s physical display has a 2560x1600 resolution, so I can easily make the window larger than 1920x1080.
That is a point. Sorry for that. I had the impression, that you did not follow the steps completely, got slightly annoyed and wrote out of experience running into assumptions. I often have long-running tmux sessions and lately also dealt with a dm not closing the session properly, leading to pipewire running in the wrong session, dbus depending commands breaking etc. I mostly wanted to say, it is running in a different environment/session, because that is, what usually breaks Wayland/X/Dbus stuff. Plus I already had confirmed with loginctl, that it is session/environment related.
I still have a feeling you are missing a step. So:
You switched to scaled mode (yes).
You logged in (yes).
You logged out via LXQt menu (yes?!)
You logged back in (no?)
You did then not see a resolution change with your setup? Well, for me this is perfectly reproducible.
If so, I have no idea why you can not reproduce this, but you might be missing some of the above steps. The result should be, that wlr-resize-watcher has still the same pid after the second login. Is that reproducible? My point is, that it then lives in a different environment/session, so wlr-randr using wayland_client.h using an old socket, which may be recreated on a different path with the second login can not connect or connects to a stale/dead session.
Sure, but the actual result here is, that no notifications are shown on resolution changes and the resolution is not preserved, which indicates an environment or socket change.
Looking forward to your findings and sorry for the garbage info in between. Can be collected.
Are you setting your resolution to something other than 1920x1080, and then when logging back in your resolution is being set back to 1920x1080? If so, that’s an anti-fingerprinting feature in wlr-resize-watcher, attempting to make your display resolution the same as most other Whonix users. If the resolution change you’re seeing is changing from some resolution to another resolution other than 1920x1080, I’m not sure what’s happening.
I see. What gives you wlr-randr as guest resolution after logout? Does it change compared to the previous one? I found it quite hard to trigger guest resolution changes in Virtualbox. It mostly does not seem to care about window resizes, at least with my compositor. The scaled resolution seems to be unnecessary. Guest resolution changes only seem to occur after logout and login. View→”Adapt to guest view” seems to trigger wlr-resize-watcher on the first login, but just once during that session. No matter what I do, the virtual resolution does not change after that. I switched to 2560x1600 on my host monitor, but it is still reproducible. However, since vm window resizing does not trigger guest resolution changes with my host compositor, it only reproduces after the second+ login.
No, wlr-randr gives me 1920x1080 as current before logout.
I got a nice log from wlr-resize-watcher, indicating that dbus and wl_display are not reachable. Dbus is just for the notifications, which has indeed nothing to do with the resolution change. The resolution changes to 1897x1421. Hope this helps.
workstation user ~]% wlr-randr
Virtual-1 "(null) (null) (Virtual-1)"
Make: (null)
Model: (null)
Serial: (null)
Enabled: yes
Modes:
1897x1421 px, 59.999001 Hz (preferred, current)
4096x2160 px, 60.000000 Hz
4096x2160 px, 59.939999 Hz
2560x1600 px, 59.987000 Hz
2560x1600 px, 59.972000 Hz
1920x1440 px, 60.000000 Hz
1856x1392 px, 59.994999 Hz
1792x1344 px, 60.000000 Hz
2048x1152 px, 60.000000 Hz
1920x1200 px, 59.884998 Hz
1920x1200 px, 59.950001 Hz
1920x1080 px, 60.000000 Hz
1600x1200 px, 60.000000 Hz
1680x1050 px, 59.953999 Hz
1680x1050 px, 59.882999 Hz
1400x1050 px, 59.978001 Hz
1400x1050 px, 59.948002 Hz
1600x900 px, 60.000000 Hz
1280x1024 px, 60.020000 Hz
1440x900 px, 59.887001 Hz
1440x900 px, 59.901001 Hz
1280x960 px, 60.000000 Hz
1366x768 px, 59.790001 Hz
1366x768 px, 60.000000 Hz
1360x768 px, 60.014999 Hz
1280x800 px, 59.810001 Hz
1280x800 px, 59.910000 Hz
1280x768 px, 59.869999 Hz
1280x768 px, 59.994999 Hz
1280x720 px, 60.000000 Hz
1024x768 px, 60.004002 Hz
800x600 px, 60.317001 Hz
800x600 px, 56.250000 Hz
848x480 px, 60.000000 Hz
640x480 px, 59.939999 Hz
Position: 0,0
Transform: normal
Scale: 1.000000
Adaptive Sync: disabled
[workstation user ~]% systemctl --user status wlr-resize-watcher
â—Ź wlr-resize-watcher.service - wlr-resize-watcher dynamic screen resolution adjustment
Loaded: loaded (/usr/lib/systemd/user/wlr-resize-watcher.service; static)
Active: active (running) since Mon 2026-04-13 11:56:32 UTC; 2min 11s ago
Invocation: d0393c54e4f2414e983c099e310f12b0
Main PID: 4113 (wlr-resize-watc)
Tasks: 1 (limit: 9507)
Memory: 9.5M (peak: 22.7M)
CPU: 261ms
CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/wlr-resize-watcher.service
└─4113 /usr/bin/python3 -su /usr/bin/wlr-resize-watcher
Apr 13 11:58:14 host wlr-resize-watcher[4113]: INFO: sync_hw_resolution_with_compositor start (card_name='card0')
Apr 13 11:58:14 host wlr-resize-watcher[4113]: INFO: Dynamic resolution disabled by config. Skipping sync.
Apr 13 11:58:14 host wlr-resize-watcher[4113]: INFO: warn_on_dynamic_resolution_refuse=1 -> sending notify and disabling further warnings.
Apr 13 11:58:14 host wlr-resize-watcher[4583]: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files
Apr 13 11:58:14 host wlr-resize-watcher[4588]: Failed to create wl_display (No such file or directory)
Apr 13 11:58:14 host wlr-resize-watcher[4588]: qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found.
Apr 13 11:58:14 host wlr-resize-watcher[4588]: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Apr 13 11:58:14 host wlr-resize-watcher[4588]: Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
Apr 13 11:58:17 host wlr-resize-watcher[4113]: INFO: sync_hw_resolution_with_compositor start (card_name='card0')
Apr 13 11:58:17 host wlr-resize-watcher[4113]: INFO: Dynamic resolution disabled by config. Skipping sync.
OK, I finally figured it out. The steps I took to reproduce the issue ended up being a bit long, but the reproduction steps I got in the end were:
Ensure “Dynamic Resolution” is disabled.
Log into the workstation, wait for it to automatically resize itself to 1920x1080 if necessary.
Grow the VirtualBox window. This results in wlr-resize-watcher warning that it is not going to resize the desktop resolution for privacy reasons.
Log out of LXQt, and then very quickly log back in. If you wait too long after logging out, the bug will not reproduce.
The desktop resolution is not 1920x1080 upon logging back in, and it never changes itself back to 1920x1080.
I was having a hard time reproducing it myself because I wasn’t trying to resize the window before logging out and back in, and I was taking too long between the logout and login steps. You’re right that this is probably because wlr-resize-watcher isn’t getting killed immediately after logout (I’ve noticed this behavior in some other scenarios, I don’t know why exactly it occurs, but I think it’s a systemd thing). I don’t think it’s probably practical to try to force the service to be killed and restarted even after a rapid logout/login cycle, so it’s probably better to create some sort of “thing” (probably a UNIX socket) that will allow the login process to tell wlr-resize-watcher that it needs to resize the display if dynamic resolution is disabled.
Edit: And now looking back up a bit, I see your suggestion to restart wlr-resize-watcher on login rather than start it. That will work, I’ll integrate that.
The long list of things I did that finally reproduced the issue
First, I deleted all existing Whonix-Gateway and Whonix-Workstation VMs from VirtualBox.
Then, in VirtualBox, I clicked File → Import Appliance..., selected a previously downloaded Whonix-LXQt-18.1.6.4.Intel_AMD64.ova file, and clicked “Open”.
In the “Import Virtual Appliance” window, I expanded “Settings”, set the “Machine Base Folder” to my usual VM location (/srv/data/VM/VBox), then clicked Finish.
When the “Software License Agreement” popup appeared, I clicked “Agree”.
The VM import process started, I waited until the “Importing appliance …” progress bar went away.
With the VMs imported, I double-clicked Whonix-Gateway-LXQt, then Whonix-Workstation-LXQt, to launch both of them.
In each VM’s GRUB menu, I booted into PERSISTENT Mode | SYSMAINT Session | system maintenance tasks.
Once both VMs finished booting, I clicked the “Install Updates” button in the “System Maintenance Panel” window on both VMs, and installed all available updates normally.
Once both VMs finished installing updates, I rebooted both of them at the same time, and let them both automatically boot into PERSISTENT Mode | USER Session | daily activities. Upon bootup, both VMs appeared to have a display resolution of 1920x1080.
When the “Whonix Setup Wizard” appeared in each VM, I clicked the “OK” button in both VMs. “systemcheck” windows appeared shortly thereafter. I waited for “systemcheck” to finish running.
Once “systemcheck” finished running and displayed reports in both VMs, I clicked the “OK” button in each report to dismiss it. From this point, I stopped interacting with the Whonix-Gateway VM and left it running in the background.
In Whonix-Workstation, I launched the wdisplays app (which appears in the start menu under the name “Displays”). It confirmed that the display resolution in Whonix-Workstation was 1920x1080. I then closed wdisplays.
To ensure that wlr-resize-watcher was paying attention to the window size, I resized the VirtualBox window. This resulted in a notification and a popup window from “wlr-resize-watcher”, reporting that the screen resolution was not being changed to improve privacy.
I clicked “OK” in the wlr-resize-watcher window (without checking the “Do not show this message again” box), and allowed the wlr-resize-watcher notification to disappear on its own.
I then clicked on the Start Menu → Leave → Logout, and clicked “Yes” when asked if I wanted to log out. The VM window changed to a smaller size, then back to a larger one, displaying the greetd login window.
I typed user into greetd, then pressed Enter. The VM window shrank again, then grew to its original size (which appeared somewhat larger than 1920x1080), then shrank to a smaller size (not as small as initially) that looks like 1920x1080. This is expected behavior, labwc starts up with the native screen resolution it detects from VirtualBox (which is bigger than 1920x1080 because of the earlier window resize), then when wlr-resize-watcher kicks in, it notices that dynamic resolution isn’t enabled and forces the display to 1920x1080.
I opened the Start Menu, launched Displays/wdisplays again, and confirmed that the display resolution was now 1920x1080. I then closed the wdisplays window.
I resized the Whonix-Workstation VirtualBox window again, which resulted in another notification and popup window from wlr-resize-watcher. I let the notification disappear on its own, and clicked “OK” in the popup window to dismiss it.
In the hopes of reproducing wrong behavior by moving quickly, I rebooted the workstation, let it boot into `PERSISTENT Mode | USER Session | daily activities", waited for the desktop to appear, grew the VirtualBox window, dismissed the wlr-resize-watcher notifications, logged out, and logged back in as quickly as possible. This resulted in the bug occurring.
Thanks for adding the change, keeping up your tries and finding the timing issue. I just did not figure relogin timing to be important. Guess I type fast, since I never did not reproduce it.
Side note: I also recreated the VM from appliance to exclude configuration tinkering as a root cause. Thanks again for your time.
