When I try to switch GNOME to Plasma KDE or XFCE with GDM logn screen, GDM shows a blank screen and bring back to the GDM login screen soon and cannot start the desktop sessions in Fedora 23. I don't see this issue in Fedora 22 but I can observe it in two Fedora 23 hosts. gdm-3.17.90-1.fc23.x86_64 There is no /var/log/Xorg.*.log . % journalctl -e _COMM=gdm-x-session Sep 15 19:13:55 u.nrt.redhat.com /usr/libexec/gdm-x-session[19487]: Sep 15 19:13:55 u.nrt.redhat.com /usr/libexec/gdm-x-session[19487]: Sep 15 19:13:55 u.nrt.redhat.com /usr/libexec/gdm-x-session[19487]:
I suspect this is not necessarily just switching desktops, I just cannot log again after I closed a session (even with the same desktop, GNOME included). Steps to reproduce: 1. Log in GNOME X11 session 2. Log out to return to gdm login screen 3. Try to log in again Actual result: The journal shows X can't acquire the console anymore: Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: (EE) Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: Fatal server error: Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: (EE) xf86OpenConsole: Cannot open virtual console 2 (Permission denied) Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: (EE) Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: (EE) Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: Please consult the Fedora Project support Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: at http://wiki.x.org Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: for help. Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: (EE) Please also check the log file at "/home/jdoe/.local/share/xorg/Xorg.0.log" for additional information. Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: (EE) Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: (EE) Server terminated with error (1). Closing log file. Sep 15 17:00:54 x61 gdm[932]: GdmDisplay: display lasted 0.181329 seconds Sep 15 17:00:54 x61 /usr/libexec/gdm-x-session[6513]: Unable to run X server Additional info: The same happens with Wayland as well Sep 15 17:10:32 x61 audit[5899]: USER_AUTH pid=5899 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_unix,pam_gnome_keyring acct="jdoe" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success' Sep 15 17:10:32 x61 audit[5899]: USER_ACCT pid=5899 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="jdoe" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success' Sep 15 17:10:32 x61 audit[5899]: CRED_ACQ pid=5899 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_unix,pam_gnome_keyring acct="jdoe" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success' Sep 15 17:10:32 x61 audit[5899]: USER_ROLE_CHANGE pid=5899 uid=0 auid=1001 ses=8 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty2 res=success' Sep 15 17:10:32 x61 gdm-password][5899]: pam_systemd(gdm-password:session): Cannot create session: Already occupied by a session Sep 15 17:10:32 x61 gdm-password][5899]: pam_unix(gdm-password:session): session opened for user jdoe by jdoe(uid=0) Sep 15 17:10:32 x61 audit[5899]: USER_START pid=5899 uid=0 auid=1001 ses=8 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_console,pam_selinux,pam_keyinit,pam_namespace,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_gnome_keyring acct="jdoe" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty2 res=success' Sep 15 17:10:32 x61 audit[5899]: USER_LOGIN pid=5899 uid=0 auid=1001 ses=8 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1001 exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success' Sep 15 17:10:33 x61 /usr/libexec/gdm-wayland-session[5910]: Unable to register display with display manager Sep 15 17:10:33 x61 gdm-password][5899]: pam_unix(gdm-password:session): session closed for user jdoe
are you guys using autologin ?
(In reply to Ray Strode [halfline] from comment #2) > are you guys using autologin ? Nope, not here.
Step 1: - First login screen - I am already logged as ofourdan via ssh $ loginctl SESSION UID USER SEAT 2 1000 ofourdan c3 42 gdm seat0 2 sessions listed. Step 2: - Login as jdoe - works fine $ loginctl SESSION UID USER SEAT 14 1001 jdoe seat0 2 1000 ofourdan c3 42 gdm seat0 3 sessions listed. Step 3: - Log-out - jdoe is still listed?! $ loginctl SESSION UID USER SEAT 14 1001 jdoe seat0 2 1000 ofourdan c3 42 gdm seat0 Step 4: - Try to get its status - but now it's gone! $ loginctl session-status 14 Failed to get session: No session '14' known Step 5: Try to log-in as "jdoe" again, it works now... $ loginctl SESSION UID USER SEAT 16 1001 jdoe seat0 2 1000 ofourdan c3 42 gdm seat0 Step 6: - Log-out - jdoe is still listed $ loginctl SESSION UID USER SEAT 16 1001 jdoe seat0 2 1000 ofourdan c3 42 gdm seat0 3 sessions listed. Step 7 - Try to get the status again, this time I am fast enough $ loginctl session-status 16 16 - jdoe (1001) Since: Tue 2015-09-15 17:44:07 CEST; 26s ago Leader: 11999 Seat: seat0; vc4 TTY: /dev/tty4 Service: gdm-password; type x11; class user State: closing Unit: session-16.scope └─12391 /usr/bin/pulseaudio --start --log-target=syslog Sep 15 17:44:28 x61 /usr/libexec/gdm-x-session[12055]: (II) systemd-logind: releasing fd for 13:69 Sep 15 17:44:28 x61 org.freedesktop.Tracker1[12120]: Received signal:15->'Terminated' Sep 15 17:44:28 x61 org.freedesktop.Tracker1[12120]: OK Sep 15 17:44:28 x61 /usr/libexec/gdm-x-session[12055]: (II) evdev: Power Button: Close Sep 15 17:44:28 x61 /usr/libexec/gdm-x-session[12055]: (II) UnloadModule: "evdev" Sep 15 17:44:28 x61 /usr/libexec/gdm-x-session[12055]: (II) systemd-logind: releasing fd for 13:66 Sep 15 17:44:28 x61 org.gnome.evolution.dataserver.Calendar7[12120]: (evolution-calendar-factory-subprocess:12898): GLib-GIO-WARNING **: Err Sep 15 17:44:28 x61 org.gnome.evolution.dataserver.AddressBook9[12120]: (evolution-addressbook-factory-subprocess:12913): GLib-GIO-WARNING * Sep 15 17:44:28 x61 /usr/libexec/gdm-x-session[12055]: (II) Server terminated successfully (0). Closing log file. Sep 15 17:44:28 x61 gdm-password][11999]: pam_unix(gdm-password:session): session closed for user jdoe => So I think something takes some time and holds the session for a little longer than expected?
Looks like a problem with systemd, upgrading to systemd-226-1.fc24 (from rawhide) solves the issue for me.
(In reply to Ray Strode [halfline] from comment #2) > are you guys using autologin ? No, I'm not. (In reply to Olivier Fourdan from comment #5) > Looks like a problem with systemd, upgrading to systemd-226-1.fc24 (from > rawhide) solves the issue for me. Right. After I update systemd-222-2.fc23.x86_64 to systemd-226-1.fc24.x86_64, I don't see this problem.
Moving to systemd then.
Any chances to back port systemd-226-1?
It looks to me like the relevant change is probably: https://github.com/systemd/systemd/commit/281033284352ed7651e84d228dad780dc2ef299f Which should be easy to backport (but note https://github.com/systemd/systemd/commit/e6494a07cbbfa93dd83782fa1f8554aa4d2353bd which prevents a straight cherry-pick of that patch) It would be nice to get some fix for this bug in - it's a rather mysterious and frustrating problem to the user.
I've been able to reproduce this problem reliably with F23 TC1 installed and fully updated from stable repos. If you log out, it takes 20 seconds until you can log in again. During that time, your password is not rejected, but gdm just flashes and returns you back to login screen. I attach a demonstration video and a full log. Furthermore, I've been able to several times reproduce a security issue that I can log in without knowing user's password. During the initial 20 seconds, the user tried to input his correct password and even some incorrect passwords several times and then possibly left the computer. I could then log in by simply clicking on his/her username - no password prompt was shown and I was logged in. However, I haven't found a reproducible steps for this and I haven't managed to record this in a video. I'm not sure if it is or is not related to this bug. For the blocker bug nomination: This might be a conditional violation of " A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility. " https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria#Expected_installed_system_boot_behavior (however, this is not after boot but after log out, and holds for 20 seconds) or this "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. " https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria#Shutdown.2C_reboot.2C_logout (log out does not work properly, because user can't re-log in for another 20 seconds)
Created attachment 1079908 [details] bug demonstration video
Created attachment 1079909 [details] journal of ignored re-login attempts This is not from the same run as the video, but I repeated the same steps - try to re-log in until 20 seconds runs out and it works again. I have tried both correct and incorrect passwords.
Created attachment 1079910 [details] rpm -qa Important packages: systemd-222-6.fc23.x86_64 gdm-3.18.0-1.fc23.x86_64 gnome-shell-3.18.0-1.fc23.x86_64 xorg-x11-server-Xorg-1.18.0-0.4.20150907.fc23.x86_64
Please, give this scratch build a try. I have backported a few logind patches from upstream. http://koji.fedoraproject.org/koji/taskinfo?taskID=11334432
Discussed at 2015-10-05 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-10-05/f23-blocker-review.2015-10-05-16.00.html . As the potential security issue isn't clearly demonstrated yet, we voted only on the known aspect of the bug (login attempts within ~20 seconds of logging out fail), and decided that while annoying, it's not a significant enough breach of the criterion to constitute a release blocker. It would be very good to fix it, though, and it's accepted as a freeze exception issue.
(In reply to Jan Synacek from comment #14) > Please, give this scratch build a try. I have backported a few logind > patches from upstream. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=11334432 I verified the fix.
systemd-222-7.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-d48443ab35
(In reply to Fedora Update System from comment #17) > systemd-222-7.fc23 has been submitted as an update to Fedora 23. > https://bodhi.fedoraproject.org/updates/FEDORA-2015-d48443ab35 This fixes this problem. I hope it also resolves the security issue, because it seems to remove the way how to make use of it.
systemd-222-7.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update systemd' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-d48443ab35
systemd-222-7.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
The problem with login in 20 seconds in GDM after logout still persists. It has been observed in Fedora 23 after FedUp upgrade from F22. systemd-222-10.fc23.x86_64 gdm-3.18.2-1.fc23.x86_64
I noticed a similar problem with F23, fresh netinstall, system up to date. After logout, I cannot immediately relogin.
I can confirm, did today a fresh netinstall of fc23, added thereafter xfce. After adding a user there is no 20 seconds delay, after 5 minnutes I still can not logon. I did a telinit 3 (on console) followed by telinit 5 and I was back in business. Hope the systemd and desktop guys can put back control-alt-backspace in service again. I checked on systemd updates: no updates, running 222-10, still a problem !
Same problem here. using systemd-222-10. For me it helps to switch to console (ctrl+F2) and back (ctrl+F1) to be able to login again. Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: (II) VESA: driver for VESA chipsets: vesa Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: (EE) Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: Fatal server error: Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: (EE) xf86OpenConsole: Cannot open virtual console 2 (Permission denied) Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: (EE) Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: (EE) Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: Please consult the Fedora Project support Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: at http://wiki.x.org Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: for help. Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: (EE) Please also check the log file at "/home/justin/.local/share/xorg/Xorg.0.log" for additional information. Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: (EE) Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor Dec 27 10:31:38 localhost audit: USER_END pid=4490 uid=0 auid=1000 ses=5 msg='op=PAM:session_close grantors=pam_selinux,pam_loginuid,pam_console,pam_selinux,pam_keyinit,pam_ namespace,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_gnome_keyring,pam_ecryptfs acct="justin" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty2 res=success' Dec 27 10:31:38 localhost audit: USER_LOGOUT pid=4490 uid=0 auid=1000 ses=5 msg='uid=1000 exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success' Dec 27 10:31:38 localhost audit: CRED_DISP pid=4490 uid=0 auid=1000 ses=5 msg='op=PAM:setcred grantors=pam_unix,pam_gnome_keyring,pam_ecryptfs acct="justin" exe="/usr/libexe c/gdm-session-worker" hostname=? addr=? terminal=/dev/tty2 res=success' Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: (EE) Server terminated with error (1). Closing log file. Dec 27 10:31:38 localhost /usr/libexec/gdm-x-session: Unable to run X server Dec 27 10:31:38 localhost gdm: GdmDisplay: display lasted 0.039422 seconds
Yes, the problem is back, I've seen it on my F23 as well.
Bug 1260487 seems to be a duplicate of this one.
Right. unfortunately the similar problem can be reproduced in f23 again.
*** Bug 1260487 has been marked as a duplicate of this bug. ***
After systemd is downgraded, the problem is not reproduced. # dnf downgrade systemd systemd-libs systemd-compat-libs # rpm -q systemd systemd-libs systemd-compat-libs systemd-222-7.fc23.x86_64 systemd-libs-222-7.fc23.x86_64 systemd-compat-libs-222-7.fc23.x86_64
(In reply to fujiwara from comment #29) > After systemd is downgraded, the problem is not reproduced. > > # dnf downgrade systemd systemd-libs systemd-compat-libs > # rpm -q systemd systemd-libs systemd-compat-libs > systemd-222-7.fc23.x86_64 > systemd-libs-222-7.fc23.x86_64 > systemd-compat-libs-222-7.fc23.x86_64 Seems to be a workaround. Thank you!
Playing a little bit with most recent systemd versions found on KOJI: Both systemd-222-10 and systemd-222-9 show the defective behaviour.
I backported a batch of patches in 222-9, one of which probably broke this again. I'll take a look.
*** Bug 1295211 has been marked as a duplicate of this bug. ***
systemd-222-11.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-361dd30f43
(In reply to Fedora Update System from comment #34) > systemd-222-11.fc23 has been submitted as an update to Fedora 23. > https://bodhi.fedoraproject.org/updates/FEDORA-2016-361dd30f43 Runs for me :-)
working for me as well
Well, it does fix the issue. However, the logout now takes ~15 seconds longer. Basically the same time for which we weren't able to log in again, we now need to wait to log out (and then relogin can be performed immediately). During that time it seems like nothing is happening (I can still work with my desktop, I just can't display the logout dialog again). Not sure if it is actually better this way. It seems that there is still some underlying problem which was not fixed, just shuffled around.
(In reply to Kamil Páral from comment #37) > Well, it does fix the issue. However, the logout now takes ~15 seconds > longer. Not on my box with a gnome3 session: logout is done immediately, and the following login too. Same with xfce or lxde sessions.
(In reply to Joachim Backes from comment #38) > Not on my box with a gnome3 session: logout is done immediately, and the > following login too. Same with xfce or lxde sessions. OK, in that case something might be wrong with my GNOME 3 session and I'll need to debug it when I have time.
See also: https://bugzilla.gnome.org/show_bug.cgi?id=750508
I think Fedora 24 also needs to be updated.
systemd-222-11.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-361dd30f43
(In reply to fujiwara from comment #41) > I think Fedora 24 also needs to be updated. Have you tried? It's a different code base that already includes the patches.
systemd-222-11.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Jan Synacek from comment #43) > (In reply to fujiwara from comment #41) > > I think Fedora 24 also needs to be updated. > > Have you tried? It's a different code base that already includes the patches. OK, I see. Yesterday I saw a similar problem in f24 but don't see it today. I guess my problem might not be a systemd issue.