GNOME Bugzilla – Bug 775619
make gnome-shell recover from an extension error
Last modified: 2021-07-05 14:22:36 UTC
Every time there is a problem in gstreamer1-vaapi (I assume the video acceleration fails or returns as unavailable or something), g-s-t fails to start and therefore the whole GNOME session fails to start - I see only a gray screen with frozen cursor, with no option to get out of it (not even Ctrl+Alt+Fx, only sysrq works). See the problem described here: https://bugzilla.redhat.com/show_bug.cgi?id=1373217 Please make g-s-t more resilient to gstreamer1-vaapi problems. No software will ever be 100% working, we need system parts to be able to recover from errors of different pieces.
gnome-settings-daemon-3.22.1-1.fc25.x86_64
I don't see how it can be resilient against system crashes caused by components it does not use. I also don't see any information in the downstream bug that would help me root cause this problem.
So, after further debugging I found out this problem is related to EasyScreenCast extension [1]. If I disable it, the login works fine - probably because nothing touches vaapi during login. But if EasyScreenCast is enabled, the login is stuck. Either downgrading gstreamer1-vaapi to 1.10.0-1.fc25, or removing it completely solves the problem. I suspected g-s-d fault, because when the login is frozen, I see this appearing in journal after 90 seconds: Dec 05 15:10:42 dryad gnome-session[1793]: gnome-session-binary[1793]: WARNING: Application 'gnome-settings-daemon.desktop' failed to register before timeout Dec 05 15:10:42 dryad gnome-session-binary[1793]: WARNING: Application 'gnome-settings-daemon.desktop' failed to register before timeout Dec 05 15:10:42 dryad gnome-session-binary[1793]: Unrecoverable failure in required component gnome-settings-daemon.desktop The full journal is here: https://bugzilla.redhat.com/attachment.cgi?id=1228071 Now, this might or might not be a fault of the extension (or a fault of gstreamer). I'm a bit surprised it even involves g-s-d, because I thought extensions only modify gnome-shell code. Either way, is there something that could be done to prevent these issues for this and similar extensions? Can I help you debug why g-s-d is timing out? Or is the error message just a red herring and this is not about g-s-d at all? Thanks. [1] https://extensions.gnome.org/extension/690/easyscreencast/
I'm guessing that gnome-settings-daemon is waiting for X to arrive, but won't, because gnome-shell, which starts the XWayland server on-demand is hanging. The root cause is gnome-shell hanging, and the extension causing the shell to hang. There's really nothing gnome-settings-daemon can do there. Feel free to reassign this bug to gnome-shell, or gstreamer for the vaapi plugin.
Since we're already dealing with easyscreencast+gstream issue here: https://bugzilla.redhat.com/show_bug.cgi?id=1373217 https://bugzilla.redhat.com/show_bug.cgi?id=1394755 I'm going to re-purpose this bug to ask gnome-shell developers if gnome-shell could somehow recover from these issues. For example, if it is not started in X seconds or it doesn't respond to events etc, could it restart itself with all extensions disabled? (This is all under Wayland).
(I can't get rid of the NEEDINFO status)
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.