Description of problem: When in KDE one selects exit > reboot, the system does not reboot. Note: rebooting from KDM itself works. Version-Release number of selected component (if applicable): kde-workspace.x86_64 4.8.0-10.fc17 @updates-testing kde-workspace-libs.x86_64 4.8.0-10.fc17 @updates-testing libkworkspace.x86_64 4.8.0-10.fc17 @updates-testing kde-settings-kdm.noarch 4.8-5.fc17 @koji-override-1/$releasever kdm.x86_64 4.8.0-10.fc17 @updates-testing How reproducible: allways Steps to Reproduce: 1. log in 2. exit... > reboot 3. xorg closes, a new kdm appears. Actual results: non-tecnical people might find it difficult to reboot the system. i issue an init 6 from a konsole session, that is not optimal Expected results: the system should reboot Additional info:
I can reproduce the problem, but I am seeing no indication of systemd receiving a request to reboot. I can reboot successfully using both logind's and ConsoleKit's D-Bus interfaces. I conclude that the bug is somewhere else than systemd. Reassigning to kde-workspace.
KDM uses this code (in the KDM backend, which always runs as root) to shut down or reboot: https://projects.kde.org/projects/kde/kde-workspace/repository/entry/kdm/backend/dm.c?rev=KDE%2F4.8#L316 where the commands default to the following: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/kdm/config.def#L41 and we override HaltCmd in kde-settings: https://fedorahosted.org/kde-settings/browser/trunk/etc/kde/kdm/kdmrc#L140 (because in the past, KDM defaulted to halting rather than powering off; this has changed recently, so I guess we could just use the default). The /sbin/shutdown and /sbin/poweroff binaries are part of systemd. They always worked in previous releases and KDM did not change.
(The default commands used last changed in kde-workspace 4.7's KDM, which just works in Fedora 16. The few lines of code in dm.c haven't changed for ages.)
(In reply to comment #2) > The /sbin/shutdown and /sbin/poweroff binaries are part of systemd. They always > worked in previous releases and KDM did not change. The commands work fine. "/sbin/shutdown -r now" reboots the machine as expected. Rebooting directly from the KDM screen works fine as well, because it uses the command. But the command is just not executed when I try to restart from the menu in a KDE session (kickoff button -> Leave -> Restart -> Restart Computer). I even replaced /sbin/shutdown with a script that logs its execution to verify this.
Huh? Shutting down through KDM shouldn't have changed at all between Fedora 16 and 17, why did this work before and not now?
*** Bug 797168 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Huh? Shutting down through KDM shouldn't have changed at all between Fedora 16 > and 17, why did this work before and not now? Could it be related to SELinux? I do not have a F17 at my disposition to try. Just a guess.
No, it's reproducible even with selinux=0.
It works with systemd-39, which makes me think that this thread is relevant for kdm: http://lists.freedesktop.org/archives/systemd-devel/2012-February/004445.html
I see this issue on my fully updated bare metal F17 machine with kde-workspace 4.8.0-11.fc17 and systemd-43, however on the *same* system in kvm I can't reproduce it.
@Martin, SELinux-policy version -89 had some sort of 'workaround' (you can also call it a bug) so that rebooting worked as expected. Try running SELinux in permissive mode or disable it and you'll see that you can't directly reboot from within KDE. The reboot option in kdm does work. With version -91 and higher of SELinux direct rebooting is not longer possible. IMHO I also think that systemd is the culprit and not SELinux. Martin Kho
(In reply to comment #8) > No, it's reproducible even with selinux=0. selinux=0 disable selinux, so you might have mislabeled objects now. You should use enforcing=0 (permissive mode) in the future.
I am well aware of that, but thanks for your concern.
(In reply to comment #11) > IMHO I also think that systemd is the culprit We now know that the problem appeared after a change in systemd. What we don't know is whether that change itself is buggy, or whether it merely exposed a latent bug. This is the change: http://cgit.freedesktop.org/systemd/systemd/commit/?id=9b221b63e5cc62439b32bb487775856a78c6015a And I repeat the link to a related discussion on the systemd mailing list: http://lists.freedesktop.org/archives/systemd-devel/2012-February/004445.html I admit I don't comprehend that completely.
(In reply to comment #11) > ... Try running SELinux in permissive > mode or disable it and you'll see that you can't directly reboot from within > KDE... You're right, I forgot to disable selinux on my VM, sorry about that, please ignore my earlier comment.
Hi, In a few posts later in the thread that Michal mentioned in comment #14, Lennard says something about the greeter (Lightdm) and it's own PAM session: "The greeter should have its own PAM session so that systemd-logind know about it and can rearrange access control to devices such as soundcards properly, so that screenreaders and event sounds work." [1] KDM also uses a greeter (kdm_greet), if I'm right. I don't know how kdm_greet is run and if Lennard's remark is relevant for the current issue. Martin Kho [1] http://lists.freedesktop.org/archives/systemd-devel/2012-February/004464.html
AFAIK, kdm_greet doesn't have its own PAM session, and in fact runs as root by default.
confirmed the assertion that manually running 'reboot' inside of a kde session, does in fact, not reboot.
Fwiw, my session ended, but just saw a black screen afterward.
Oh, BTW, the reboot in KDM is triggered from the backend, NOT from the greeter.
(In reply to comments #18, #19) > confirmed the assertion that manually running 'reboot' inside of a kde session, > does in fact, not reboot. > Fwiw, my session ended, but just saw a black screen afterward. This may be a different bug. It works for me.
selinux in either enforcing or permissive does not change things, kde still does not reboot. > confirmed the assertion that manually running 'reboot' inside > of a kde session, reboot, executed from konsole does indeed work ok (aka reboot).
The process that executes kdm/backend/session.c:manageSession() is the leader process of the logind session. manageSession() calls: blockTerm(); clientExited(); unblockTerm(); where clientExited() ends the PAM session. With the current systemd-logind, ending the PAM session will cause the leader process to be delivered SIGHUP and SIGTERM. The process will die and the remainder of manageSession() will not be executed. Interestingly, at the end of the function there's a call to sessionExit(), which calls clientExited() again. Removing the three lines quoted above makes reboot from KDE work again. I haven't noticed any bad effects.
Thanks Michal! I'll try patching as suggested (and poke kdm upstream).
Michal, thanks for your good debug analyse, it's cleary that these code won't work with the change in systemd in comment 16. I don't know which effects could caused with removing above three lines. But it could be a workaound temporary before we have an correct fix.
kde-workspace-4.8.0-12.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/kde-workspace-4.8.0-12.fc17
Thank you for the analysis and the KDM fix! However, I think that this is a bug (regression) in systemd, it should not run around killing processes for no reason, the login manager will exit itself! You're still going to unnecessarily kill KDM later on when it calls clientExited(), possibly preventing it from doing cleanups.
Lennart, could you explain the purpose of commit "logind: if we have to stop a session, kill at least its leader"?
Package kde-workspace-4.8.0-12.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kde-workspace-4.8.0-12.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-2639/kde-workspace-4.8.0-12.fc17 then log in and leave karma (feedback).
(In reply to comment #27) > Thank you for the analysis and the KDM fix! > > However, I think that this is a bug (regression) in systemd, it should not run > around killing processes for no reason, the login manager will exit itself! > You're still going to unnecessarily kill KDM later on when it calls > clientExited(), possibly preventing it from doing cleanups. you can easily catch the SIGTERM and do cleanups afterwards.
kde-workspace-4.8.0-12.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
The kdm patch may become unnecessary with this recent change in systemd: http://cgit.freedesktop.org/systemd/systemd/commit/?id=75c8e3cffd7da8eede614cf61384957af2c82a29 I haven't tested it yet.
Dropping CommonBugs nomination, as the fix is in Beta. KDE guys - note in future, bugs of this sort should probably be proposed as Beta blockers, as we have Beta criterion "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work".