Description of problem: In Fedora 31, whenever I log out of my Gnome Shell session, the GDM dies and does not offer a new login screen. Gdm must be restarted or the computer rebooted to make it work again. Version-Release number of selected component (if applicable): gdm-3.33.90-2.fc31.x86_64 How reproducible: Always Steps to Reproduce: 1. Log into Gnome. 2. Log out. Actual results: GDM dies. Expected results: New login screen is shown and enables new login. Additional info: -- Logs begin at Mon 2018-07-16 23:05:42 CEST, end at Mon 2019-08-26 13:01:37 CEST. -- Aug 26 12:34:35 platypus systemd[1]: Starting GNOME Display Manager... Aug 26 12:34:35 platypus systemd[1]: Started GNOME Display Manager. Aug 26 12:34:37 platypus gdm-launch-environment][1332]: accountsservice: Could not get current seat: No data available Aug 26 12:34:48 platypus gdm-password][1623]: accountsservice: Could not get current seat: No data available Aug 26 12:34:56 platypus gdm-password][1623]: gkr-pam: unable to locate daemon control file Aug 26 12:35:02 platypus gdm[1194]: Child process -1348 was already dead. Aug 26 12:35:57 platypus gdm-launch-environment][2499]: accountsservice: Could not get current seat: No data available Aug 26 12:38:09 platypus systemd[1]: Stopping GNOME Display Manager... Aug 26 12:38:10 platypus gdm[1194]: Child process -2516 was already dead. Aug 26 12:38:10 platypus systemd[1]: gdm.service: Succeeded. Aug 26 12:38:10 platypus systemd[1]: Stopped GNOME Display Manager. Aug 26 12:38:10 platypus systemd[1]: Starting GNOME Display Manager... Aug 26 12:38:10 platypus systemd[1]: Started GNOME Display Manager. Aug 26 12:38:10 platypus gdm-launch-environment][3136]: accountsservice: Could not get current seat: No data available Aug 26 12:38:16 platypus gdm-password][3361]: accountsservice: Could not get current seat: No data available Aug 26 12:38:27 platypus gdm-password][3361]: gkr-pam: unable to locate daemon control file Aug 26 12:38:38 platypus gdm[3132]: Child process -3140 was already dead. Aug 26 12:38:47 platypus gdm-launch-environment][3592]: accountsservice: Could not get current seat: No data available
If some more details are needed, let me know how I can get them for you. Thanks.
Proposed as a Blocker for 31-beta by Fedora user lruzicka using the blocker tracking app because: Gdm fails during gnome-shell logout and the computer is unable to login which violates at least "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops".
can you put Enable=true in the [debug] section of /etc/gdm/custom.conf , reboot, reproduce and then post the full output of # journalctl -b ?
also can you check whether booting with enforcing=0 on the kernel command line changes the outcome of the bug?
Note, I think this can actually affect simply switching between consoles during a GNOME session too. I've twice now switched to tty3 to do something at a console and not been able to switch back to the GNOME session successfully, with the same kinds of errors in the journal: Aug 26 10:01:40 adam.happyassassin.net kernel: rfkill: input handler disabled Aug 26 10:01:40 adam.happyassassin.net gnome-shell[2047]: Failed to DPMS: Failed to set connector 65 property 2: Permission denied Aug 26 10:01:40 adam.happyassassin.net kernel: rfkill: input handler enabled Aug 26 10:01:40 adam.happyassassin.net gnome-shell[2047]: Failed to CRTC gamma: drmModeCrtcSetGamma on CRTC 48 failed: Permission denied Aug 26 10:01:40 adam.happyassassin.net gnome-shell[2047]: Failed to CRTC gamma: drmModeCrtcSetGamma on CRTC 46 failed: Permission denied Aug 26 10:01:40 adam.happyassassin.net gdm-launch-environment][202818]: accountsservice: Could not get current seat: No data available Aug 26 10:01:40 adam.happyassassin.net audit[202818]: USER_AUTH pid=202818 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_permit acct="gdm" exe="/usr/libexec/gdm-> Aug 26 10:01:40 adam.happyassassin.net audit[202818]: USER_ACCT pid=202818 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_permit acct="gdm" exe="/usr/libexec/gdm-sess> Aug 26 10:01:40 adam.happyassassin.net audit[202818]: CRED_ACQ pid=202818 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grant
Discussed during the 2019-08-26 blocker review meeting: [1] The decision to classify this bug as an "AcceptedBlocker" was made as, based on the way it is described, violates the following criteria: "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops" [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-08-26/f31-blocker-review.2019-08-26-16.00.txt
My computer runs in Permissive mode, and the problem still persists. I am attaching the log files for you to investigate. One of the is the output "journalctl -b" command and the other is "journalctl -b -u gdm".
Created attachment 1608418 [details] journalctl -b output
Created attachment 1608419 [details] journalctl -b -gdm output
I'm also seeing openQA tests fail due to tty switch failing, e.g. here: https://openqa.fedoraproject.org/tests/438910 it's a bit hard to follow if you don't know how the test work, but basically what's going on here: https://openqa.fedoraproject.org/tests/438910#step/desktop_update_graphical/23 is the test ran that 'ps -C Xwayland,Xorg -o tty --no-headers' command to figure out which tty GNOME was running on, it found it was on tty1 so it did 'ctrl-alt-f1' (this we can see in the test execution log, https://openqa.fedoraproject.org/tests/438910/file/autoinst-log.txt ), and then it assumes it's at the desktop and hits 'super' then types 'update' (to try and run GNOME Software)...but in fact the tty switch didn't work and it's still at tty3 so it just types 'update' into the console.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1549 / https://github.com/systemd/systemd/issues/13437 look to be the same problem.
At least, it's the same as *my* problem, and I do think the one Lukas reported is probably caused by the same thing or just a special case of the same problem...if they turn out to be different I'll separate the reports.
Seems pretty likely that Adam is right. Let's bounce this over to systemd. Once vt switching is fixed, if there are still problems then this can be moved back to gdm.
There might be more than one thing going on here. I stumbled into this bug report because of the VT switching issue. But I've got two other failure modes, one where gdm doesn't recover from blanking the backlight; and sometimes also when logging out. So these might be dups: bug 1747845 https://gitlab.gnome.org/GNOME/gdm/issues/511
(In reply to Chris Murphy from comment #14) > There might be more than one thing going on here. I stumbled into this bug > report because of the VT switching issue. But I've got two other failure > modes, one where gdm doesn't recover from blanking the backlight; Probably a different bug. > and sometimes also when logging out. Well that would be a vt switch.
Please test https://github.com/systemd/systemd/pull/13454.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #16) > Please test https://github.com/systemd/systemd/pull/13454. Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=37436873
(In reply to Vít Ondruch from comment #17) > (In reply to Zbigniew Jędrzejewski-Szmek from comment #16) > > Please test https://github.com/systemd/systemd/pull/13454. > > Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=37436873 Chm, DNF refuses to update to that build. Strange: ~~~ $ sudo dnf update https://kojipkgs.fedoraproject.org//work/tasks/6876/37436876/systemd-{,{libs,pam,container,udev}-}243~rc2-2+1.fc32.x86_64.rpm Last metadata expiration check: 0:00:51 ago on Tue Sep 3 09:15:54 2019. Dependencies resolved. Problem: The operation would result in removing the following protected packages: kernel-core, systemd =============================================================================== Package Arch Version Repository Size =============================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): systemd-libs x86_64 243~rc2-2+1.fc32 @commandline 525 k Skipping packages with broken dependencies: systemd i686 243~rc2-2.fc32 rawhide 3.8 M systemd x86_64 243~rc2-2+1.fc32 @commandline 3.8 M systemd-container x86_64 243~rc2-2+1.fc32 @commandline 483 k systemd-pam x86_64 243~rc2-2+1.fc32 @commandline 166 k systemd-udev x86_64 243~rc2-2+1.fc32 @commandline 1.3 M Transaction Summary =============================================================================== Skip 6 Packages Nothing to do. Complete! ~~~ So here is one without release bump: https://koji.fedoraproject.org/koji/taskinfo?taskID=37436968
(In reply to Zbigniew Jędrzejewski-Szmek from comment #16) > Please test https://github.com/systemd/systemd/pull/13454. This appear to fix the switching between VT/tty. Unfortunately, it does not appear to fix the logout issue.
Resetting status appropriately.
wrt logout what seems to be happening here is is not that gdm "dies" but it never restarts because according to loginctl the user session does not exit. If one # loginctl kill-session <the-stuck-user-session> gdm restarts successfully after.
Updated with this https://koji.fedoraproject.org/koji/taskinfo?taskID=37436968 And now I can't reproduce the logout problem. Hmm...
Created attachment 1611270 [details] journal2 I spoke too soon. After a couple more login/logout iterations I get a failure: Upon the failed logout, I see in the (attached) journal... Sep 03 13:08:28 fmac.local gnome-session-binary[3060]: gnome-session-binary[3060]: DEBUG(+): GsmManager: CanShutdown called Sep 03 13:08:28 fmac.local gnome-session-binary[3060]: DEBUG(+): GsmManager: CanShutdown called Sep 03 13:08:30 fmac.local gnome-session-binary[3060]: gnome-session-binary[3060]: DEBUG(+): GsmManager: Logout called Sep 03 13:08:30 fmac.local gnome-session-binary[3060]: gnome-session-binary[3060]: DEBUG(+): GsmManager: requesting logout Sep 03 13:08:30 fmac.local gnome-session-binary[3060]: DEBUG(+): GsmManager: Logout called [snip] And the screen goes black and does not recover. gnome-shell is not running but I also do not see a crash indication anywhere in the log.
mutter-3.33.91-2.fc31.x86_64 does not fix the logout problem.
Created attachment 1611281 [details] journal3 Concur with comment 21 [chris@fmac ~]$ loginctl session-status 4 4 - chris (1000) Since: Tue 2019-09-03 14:28:04 MDT; 11min ago Leader: 1505 (gdm-session-wor) Seat: seat0; vc2 TTY: tty2 Service: gdm-password; type wayland; class user State: closing Unit: session-4.scope └─1505 gdm-session-worker [pam/gdm-password] It indefinitely hangs in this state and if I kill it with [chris@fmac ~]$ loginctl kill-session 4 graphical login screen comes back, and I can login normally, at which point there is a session 6, log out, black screen, kill session 6 and I get a text tty...that's weird. But I can switch to tty1 which is graphical login. Attaching a log showing boot until first logout, logout dialog confirmed at monotonic time 112, so the stuck part is in 112+ somewhere. systemd.log_level=debug gdm debug is set selinux=0 updated systemd from comment 18 mutter-3.33.91-2.fc31.x86_64
(In reply to Chris Murphy from comment #25) > [chris@fmac ~]$ loginctl session-status 4 > 4 - chris (1000) > Since: Tue 2019-09-03 14:28:04 MDT; 11min ago > Leader: 1505 (gdm-session-wor) > Seat: seat0; vc2 > TTY: tty2 > Service: gdm-password; type wayland; class user > State: closing > Unit: session-4.scope > └─1505 gdm-session-worker [pam/gdm-password] What does State: closing mean? Does this mean the problem that gdm-session-worker is not quitting when expected?
is this still happening after the recent fixes to gnome-session and the 3.33.92 megaupdate?
I'm not hitting this anymore, not sure what fixed it.
Thanks. It'd be good to hear from lruzicka too, though, just for confirmation.
Since yesterday, after updating the system to recent updates-testing (and on machines with 20190908 compose) I have not run into this again. Tested on a VM, on a bare machine, and on my laptop (T460s).
I haven't seen any gnome session issues either in the last day or so with latest Silverblue 31.
And I couldn't reproduce it in a VM nor on bare metal. Seems fixed. Closing.