Bug 1745554 - Login screen dies after the user has logged out of Gnome Desktop.
Summary: Login screen dies after the user has logged out of Gnome Desktop.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 31
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On: 1748401
Blocks: F31BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2019-08-26 11:06 UTC by Lukas Ruzicka
Modified: 2019-09-10 13:14 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-10 13:14:42 UTC


Attachments (Terms of Use)
journalctl -b output (676.18 KB, text/plain)
2019-08-27 08:44 UTC, Lukas Ruzicka
no flags Details
journalctl -b -gdm output (38.75 KB, text/plain)
2019-08-27 08:45 UTC, Lukas Ruzicka
no flags Details
journal2 (2.37 MB, text/plain)
2019-09-03 19:19 UTC, Chris Murphy
no flags Details
journal3 (6.97 MB, text/plain)
2019-09-03 20:48 UTC, Chris Murphy
no flags Details


Links
System ID Priority Status Summary Last Updated
Github systemd systemd issues 13437 'None' 'closed' 'logind: 243~rc2 break VT/tty switching on Fedora 31' 2019-11-13 06:15:53 UTC

Description Lukas Ruzicka 2019-08-26 11:06:35 UTC
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

Comment 1 Lukas Ruzicka 2019-08-26 11:07:31 UTC
If some more details are needed, let me know how I can get them for you. Thanks.

Comment 2 Fedora Blocker Bugs Application 2019-08-26 16:18:34 UTC
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".

Comment 3 Ray Strode [halfline] 2019-08-26 17:03:27 UTC
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

?

Comment 4 Ray Strode [halfline] 2019-08-26 17:03:59 UTC
also can you check whether booting with enforcing=0 on the kernel command line changes the outcome of the bug?

Comment 5 Adam Williamson 2019-08-26 17:59:51 UTC
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

Comment 6 Geoffrey Marr 2019-08-26 18:13:34 UTC
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

Comment 7 Lukas Ruzicka 2019-08-27 08:43:46 UTC
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".

Comment 8 Lukas Ruzicka 2019-08-27 08:44:39 UTC
Created attachment 1608418 [details]
journalctl -b output

Comment 9 Lukas Ruzicka 2019-08-27 08:45:08 UTC
Created attachment 1608419 [details]
journalctl -b -gdm output

Comment 10 Adam Williamson 2019-08-30 17:51:44 UTC
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.

Comment 11 Adam Williamson 2019-08-30 17:59:38 UTC
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1549 / https://github.com/systemd/systemd/issues/13437 look to be the same problem.

Comment 12 Adam Williamson 2019-08-30 18:03:04 UTC
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.

Comment 13 Michael Catanzaro 2019-08-30 19:47:00 UTC
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.

Comment 14 Chris Murphy 2019-09-02 04:06:49 UTC
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

Comment 15 Michael Catanzaro 2019-09-02 11:50:00 UTC
(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.

Comment 16 Zbigniew Jędrzejewski-Szmek 2019-09-02 16:13:14 UTC
Please test https://github.com/systemd/systemd/pull/13454.

Comment 17 Vít Ondruch 2019-09-03 06:45:13 UTC
(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

Comment 18 Vít Ondruch 2019-09-03 07:17:28 UTC
(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

Comment 19 Vít Ondruch 2019-09-03 07:25:27 UTC
(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.

Comment 20 Zbigniew Jędrzejewski-Szmek 2019-09-03 09:37:50 UTC
Resetting status appropriately.

Comment 21 Yanko Kaneti 2019-09-03 11:40:38 UTC
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.

Comment 22 Chris Murphy 2019-09-03 19:06:21 UTC
Updated with this
https://koji.fedoraproject.org/koji/taskinfo?taskID=37436968

And now I can't reproduce the logout problem. Hmm...

Comment 23 Chris Murphy 2019-09-03 19:19:13 UTC
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.

Comment 24 Chris Murphy 2019-09-03 20:23:16 UTC
mutter-3.33.91-2.fc31.x86_64 does not fix the logout problem.

Comment 25 Chris Murphy 2019-09-03 20:48:54 UTC
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

Comment 26 Michael Catanzaro 2019-09-04 15:27:34 UTC
(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?

Comment 27 Adam Williamson 2019-09-09 15:18:22 UTC
is this still happening after the recent fixes to gnome-session and the 3.33.92 megaupdate?

Comment 28 Chris Murphy 2019-09-09 15:30:40 UTC
I'm not hitting this anymore, not sure what fixed it.

Comment 29 Adam Williamson 2019-09-09 15:52:39 UTC
Thanks. It'd be good to hear from lruzicka too, though, just for confirmation.

Comment 30 Lukas Ruzicka 2019-09-10 09:31:15 UTC
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).

Comment 31 Jens Petersen 2019-09-10 09:51:23 UTC
I haven't seen any gnome session issues either in the last day or so with latest Silverblue 31.

Comment 32 Kamil Páral 2019-09-10 13:14:42 UTC
And I couldn't reproduce it in a VM nor on bare metal. Seems fixed. Closing.


Note You need to log in before you can comment on or make changes to this bug.