GDM's GNOME Shell floods the Journal with XFIXES/cursor issues on Buster
feature/buster, a few seconds after logging in:
amnesia@amnesia:~$ sudo journalctl | grep -c 'gnome-shell.*: Failed to create XFIXES cursor: Failed to get cursor image' [sudo] password for amnesia: 9398
I think we might have a cursor issue.
In case that matters, this is through virt-manager/libvirt.
- Type of work changed from Code to Research
FWIW I can't reproduce the bug with a feature/buster build at b8a9438cbb55ba053f4b6a701f8995e5edfa2d0d (libvirt, Spice, virtio-gpu). I only see
Initializing extension XFIXES twice (once for the GDM X session, once for the amnesia session).
Wrt. reproducing on testing/sid: to tell whether a GNOME session is using X.Org, check
$XDG_SESSION_DESKTOP; if using Wayland, the value will be
gnome; if using X.Org, it'll be
gnome-xorg. "GNOME on Xorg". I'm pretty sure the 2 GNOME sessions you see are using Wayland; no idea about the X11 thing. I think you want
/usr/share/xsessions/gnome-xorg.desktop ("GNOME on Xorg"). I see it on a Debian sid installation (it might be that GDM only displays it under some conditions); there I don't see XFIXES issues in the Journal.
So I'm curious what exactly triggers this problem in your setup and not on mine. I'll test this on bare metal.
#4 Updated by CyrilBrulebois 10 months ago
Right, those names didn't seem to match what you were suggesting.
FWIW I'm seeing this with my local branch (with only commits in
features/) which is on top of current
feature/buster, that is 7b5447201a5798abc6ba58facd581f2fa051fa7 (a few commits later than you). I'm not setting anything specific on the libvirt/virt-manager side, so I'm on
llvmpipe on the rendering side. Maybe that's why I'm not offered the same options as you are? I do see the said
gnome-xorg.desktop file in the installed system.
XDG_SESSION_DESKTOP, I'm seeing respectively:
Can't reproduce with a feature/buster build at b8a9438cbb55ba053f4b6a701f8995e5edfa2d0d on bare metal (ThinkPad X200).
Reproduced with the same ISO on a VM created with virt-manager on sid, with the default settings (QXL graphics, Spice display, generic PS2 mouse). Note that the issue is only about GDM's session (
/usr/bin/gnome-shell --mode=gdm-tails), not about the "amnesia" one.
git grep set-cursor.py in
greeter.git. I suspect that's the culprit. No idea if we still need this, iirc it's meant to display a "waiting" cursor while the Greeter is running or while logging in, or similar.
The code that logs this error seems to be https://sources.debian.org/src/mutter/3.30.2-4/src/backends/meta-cursor-tracker.c/?hl=229#L229
So, https://sources.debian.org/src/mutter/3.30.2-4/src/backends/x11/cm/meta-cursor-sprite-xfixes.c/?hl=105#L133 calls
XFixesGetCursorImage which fails in this context (QXL, GNOME on X.Org). Same problem with Cirrus graphics but works fine with virtio-gpu. My understanding is that this code is not called under Wayland.
- Reproduce on pristine Debian with GNOME on X.Org so we can report the problem upstream.
- Most likely our test suite is affected and flooding the Journal can cause all kinds of trouble => switch the test suite to virtio GPU (assuming the virt host supports it).
- To be ready in case that's not fixed in Buster, update our end-user doc about libvirt virtualization to recommend a GPU that works well and is not affected by this bug (most likely virtio, which works as well as QXL in my experience, is the current dev focus, and has host-accelerated 3d support on Buster — for which I need to fix some AppArmor things by the way).
- Affected tool set to Greeter
FTR our automated test suite is affected:
Jan 07 07:35:04 amnesia gdm-session-worker: Entering PostLogin Jan 07 07:35:04 amnesia gdm-session-worker: Running /usr/local/lib/tails-unblock-network... Jan 07 07:35:04 amnesia /usr/lib/gdm3/gdm-x-session: (II) config/udev: removing device spice vdagent tablet Jan 07 07:35:04 amnesia /usr/lib/gdm3/gdm-x-session: (II) UnloadModule: "libinput" Jan 07 07:35:04 amnesia /usr/lib/gdm3/gdm-x-session: (II) systemd-logind: releasing fd for 13:69 Jan 07 07:35:04 amnesia dbus-daemon: [session uid=1000 pid=5543] Activating via systemd: service name='org.gtk.vfs.Daemon' unit='gvfs-daemon.service' requested by ':1.1' (uid=1000 pid=5541 comm="gio set /home/amnesia/Desktop/Report_an_error.desk") Jan 07 07:35:04 amnesia gdm-session-worker: + systemctl start tails-unblock-network.service Jan 07 07:35:04 amnesia systemd: Starting Virtual filesystem service... Jan 07 07:35:04 amnesia spice-vdagentd: closed vdagent virtio channel Jan 07 07:35:04 amnesia systemd: Starting Unblock network device drivers... Jan 07 07:35:04 amnesia gnome-shell: Failed to create XFIXES cursor: Failed to get cursor image Jan 07 07:35:04 amnesia gnome-shell: Failed to create XFIXES cursor: Failed to get cursor image
As the log shows, this happens as soon as logind removes the input device from GDM's GNOME Shell. Initially I thought "oh, that's because we keep GDM's GNOME Shell instance running while Debian does not", but that's incorrect:
I can't reproduce in a Debian sid VM with QXL graphics on a sid host. #12092 suggests that X.Org vs. Wayland matters so I've tried with a GDM and user session that use both X.Org, and there I can't reproduce this problem there either and I see that GDM's GNOME Shell instance is still running after login there, just like in Tails (3.x and feature/buster both).
So there's nothing to report upstream and this seems to be a Tails Greeter specific problem => adding Alan to Cc. I'll look into our cursor hacks and if they're not at fault, I'll try the hack proposed on #12999 and see if we can integrate it properly.
This works around this problem:
+--- a/usr/lib/python3/dist-packages/tailsgreeter/gui.py ++++ b/usr/lib/python3/dist-packages/tailsgreeter/gui.py +@@ -883,9 +883,6 @@ class GreeterMainWindow(Gtk.Window, TranslatableWindow): + + def finish_login(self): + logging.info("Starting the session") +- # /usr/lib/systemd/user/tails-greeter-session-helper.service will +- # restore the cursor to the left pointer state. +- self.get_root_window().set_cursor(Gdk.Cursor.new(Gdk.CursorType.WATCH)) + self.greeter.login() + return False
Unfortunately, it removes a nice UX improvement brought by #5945. Other options that don't have this drawback:
- Keep this code but terminate the GDM session ASAP during the amnesia session setup (#12092).
- Pros: we save memory.
- Cons: there will still be lots of error messages in the Journal until the GDM session is terminated.
- Drop this code but add a user service that runs ASAP during the amnesia session setup and switches the cursor to hourglass (and then
tails-greeter-session-helper.serviceresets the cursor back to its idle state).
- Pros: no errors in the Journal and we stop fiddling in GDM with the state of a cursor we don't control anymore, which feels less risky.
- Cons: the cursor may be switched to hourglass too late, and not remain this way for long, so perhaps it's more hassle than it's worth.
- Subject changed from gnome-shell flooding the journal with XFIXES/cursor issues to GDM's GNOME Shell floods the Journal with XFIXES/cursor issues on Buster
- Status changed from Confirmed to In Progress
- Type of work changed from Research to Code
This works around this problem:
Unfortunately, it removes a nice UX improvement brought by #5945.
I've tested feature/buster without this workaround on a ThinkPad X200 and that UX improvement is actually almost a no-op (at least on Buster; did not check on Stretch): the cursor turns to hourglass only for ~1 second; during most of the login process, either the cursor is entirely hidden or it's back to the usual arrow. So it seems that dropping this "switch to hourglass after one clicks Start" does not impact UX much. Also, now that the login process does not block on installation of additional software anymore, one reason that made this UX improvement important is gone. So I'll apply this workaround and will drop the code that deals with the cursor post-login.