Description of problem: On Shutdown (rtclick on Desktop in plasma->Leave->Shutdown) I have nosplash setup) sddm restarts the login screen. It is active in the sense that I can move the mouse, enter my password, click on buttons, but of course they do not do anything since almost everything has shutdown behind the scenes. This will either stay up for about 2 sec, about 2 min, or "forever" (over 5 min-- in which case if I pressed the shutdown button on the login screen it completed the shutdown). This behaviour began suddenly (perhaps on an update I did on Feb 25) and has not stopped after I did a mass update on Mar 15. It is really annoying. I have SPLASH=no in /etc/sysconfig/bootsplash ls -la /etc/systemd/system/default.target lrwxrwxrwx 1 root root 36 Dec 22 08:38 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel5.target I am attaching an exerpt from the journalctl entry from the previous shutdown (which was one where the login screen quickly disappeared and the shutdown completed normally after that. Clearly sddm is restarting the login screen when the old X display was terminated, which it should NOT be doing. I have attached part of the journalctl log from approx where shutdown is started to the end of the shutdown. Note the sequence Line 202: Mar 18 23:33:09 planet systemd[1]: Stopping Session c2 of user sddm. Line 313: Mar 18 23:33:09 planet systemd[1]: Removed slice User Slice of sddm. Line 335: Mar 18 23:33:09 planet sddm[1528]: Display server stopped. Mar 18 23:33:09 planet sddm[1528]: Running display stop script "/usr/share/sddm/scripts/Xstop" Mar 18 23:33:09 planet sddm[1528]: Removing display ":0" ... Mar 18 23:33:09 planet sddm[1528]: Adding new display on vt 1 ... Mar 18 23:33:09 planet sddm[1528]: Display server starting... Mar 18 23:33:09 planet sddm[1528]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{11f5f075-ff0b-40c0-bfd8-cd20cc216b1f} -background none -noreset -displayfd 19 vt1 Mar 18 23:33:09 planet rsyncd[858]: sent 0 bytes received 0 bytes total size 0 Mar 18 23:33:09 planet systemd[1]: Stopped fast remote file copy program daemon. Mar 18 23:33:09 planet audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rsyncd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mar 18 23:33:09 planet sddm[1528]: Running display setup script "/usr/share/sddm/scripts/Xsetup" Mar 18 23:33:09 planet sddm[1528]: Display server started. Mar 18 23:33:09 planet sddm[1528]: Socket server starting... Mar 18 23:33:09 planet sddm[1528]: Socket server started. Mar 18 23:33:09 planet sddm[1528]: Greeter starting... Mar 18 23:33:09 planet sddm[1528]: Adding cookie to "/var/run/sddm/{11f5f075-ff0b-40c0-bfd8-cd20cc216b1f}" Mar 18 23:33:09 planet sddm-helper[21393]: [PAM] Starting... Mar 18 23:33:09 planet audit[21393]: USER_AUTH pid=21393 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_permit acct="sddm" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=success' Mar 18 23:33:09 planet audit[21393]: USER_ACCT pid=21393 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_permit acct="sddm" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=success' Mar 18 23:33:09 planet audit[21393]: CRED_ACQ pid=21393 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_permit acct="sddm" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=success' Mar 18 23:33:09 planet sddm-helper[21393]: [PAM] Authenticating... Mar 18 23:33:09 planet sddm-helper[21393]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0) Mar 18 23:33:09 planet sddm-helper[21393]: [PAM] returning. Ie, sddm is restarting the greeter and the whole login process, as if the system had not been shutdown, but was just logged out. Then sddm and systemctl fight for a while and finally systemd kills sddm-helper and sddm gets the message and allows the Display to be closed down and the system finally shuts down. But sometimes that last process does not happen at all and the sddm greeter stays there forever. Version-Release number of selected component (if applicable): sddm-0.14.0-12.mga6, How reproducible: Always Steps to Reproduce: 1.Run sddm as the dm greeter. 2.Shut down from the desktop 3.
(In reply to w unruh from comment #0) > I have SPLASH=no in /etc/sysconfig/bootsplash I can't help with the actual bug (thanks for the report), but I just wanted to point out that the above is meaningless, and has been for quite some time, but unfortunately we still have failed to do anything about it. See Bug 5138.
CC: (none) => marja11Assignee: bugsquad => kde
This bu.g is still there and is a real annoyance. For anyone else who runs into it, if you do alt-PrtScr alt-e this seems to kill the hung process the shutdown completes. This is much much faster than holding down the power button. (1-2 sec vs 10-14) I have no idea how to find out what it is that is stopping the shutdown since the sddm greeter screen covers any error messages that the shutdown might be generating. Looking at the journalctl screen from the previous boot after I reboot also does not show me anything suspicious. But this does seem to say that something is hanging. The sddm-greeter really really should not be coming up during a shutdown.
OK, the problem seems to be Plymouth. If I put plymouth.enable=0 into the grub kernel argument line, the sddm greeter still comes up (it really should not do that), but after about 4 sec, it disappears, and the shutdown proceeds to a poweroff of the laptop. Recall I am running without splash or quiet in the kenrel line. Why plymouth is running in that case I have no idea, but it seems to randomly hang on the shutdown. (I have now shutdown about 7 times with plymouth.enable=0 and it has not hung yet. Also, on those times when it did not hang, the first item in the display of the shutdown after the sddm-greeter disappeared was a line about plymouth.)
Strangely, the problem seems to be the cups canon capt driver. Wehn I removed cndrvcups-capt-2.70 rpm thelogout now flashes the sddm-greeter for about 1 sec and then completes the shutdown. Somehow that cannon driver (presumable obtained from Cannon itself since no such rpm exists in Mageia 6) seems to freeze the shutdown often ( and at the very least delays the shutdown for at least 5 sec.) Thus this bug seems to be solved.
Still solved after the mass update to kde/qt.
(In reply to w unruh from comment #4) > > Thus this bug seems to be solved. (In reply to w unruh from comment #5) > Still solved after the mass update to kde/qt. Thanks for the feedback :-) Closing.
Status: NEW => RESOLVEDResolution: (none) => FIXED