Description of problem: When turning off the computer or rebooting, the kdm.service fails to stop properly and waits for the systemd timeout, which by default is 90 seconds. This introduces a 90 seconds delay before shutting down the computer, which is pretty long. Here's what can be found in the journal: févr. 15 16:44:37 home.bompard.org systemd[1]: Started Show Plymouth Reboot Screen. févr. 15 16:46:04 home.bompard.org systemd[1]: kdm.service stopping timed out (2). Killing. févr. 15 16:46:04 home.bompard.org systemd[1]: Stopped The KDE login manager. févr. 15 16:46:04 home.bompard.org systemd[1]: Unit kdm.service entered failed state See the delay between the first line and the second. Here's another extract from the journal with debugging enabled, after I've changed the timeout to 10 seconds in the unit file: févr. 22 08:31:37 home.bompard.org systemd[1]: Installed new job kdm.service/stop as 1105 févr. 22 08:31:39 home.bompard.org systemd[1]: kdm.service changed running -> stop-sigterm févr. 22 08:31:39 home.bompard.org systemd[1]: Child 727 belongs to kdm.service févr. 22 08:31:39 home.bompard.org systemd[1]: kdm.service: main process exited, code=exited, status=0/SUCCESS févr. 22 08:31:39 home.bompard.org systemd[1]: kdm.service changed stop-sigterm -> final-sigterm févr. 22 08:31:48 home.bompard.org systemd[1]: kdm.service stopping timed out (2). Killing. févr. 22 08:31:48 home.bompard.org systemd[1]: kdm.service changed final-sigterm -> final-sigkill févr. 22 08:31:48 home.bompard.org systemd[1]: kdm.service: cgroup is empty févr. 22 08:31:48 home.bompard.org systemd[1]: kdm.service changed final-sigkill -> failed févr. 22 08:31:48 home.bompard.org systemd[1]: Job kdm.service/stop finished, result=done févr. 22 08:31:48 home.bompard.org systemd[1]: Unit kdm.service entered failed state The 10s are there. We need to either find why KDM won't be stopped, or set a smaller timeout in the unit file (TimeoutStopSec in the [Service] section). Version-Release number of selected component (if applicable): kdm-4.9.5-7.fc18.i686 kde-settings-kdm-4.9-19.fc18.noarch systemd-197-1.fc18.1.i686 How reproducible: Always
Hi, how do you turn off your computer when this happens? By using commands such as reboot in terminal, choosing to shutdown from your desktop manager's menu (and which DM is it?) or directly from KDM? Do you have any other sessions opened? Is there any difference from stock settings?
I'm choosing Shutdown or Reboot from KDE's menu. No other sessions opened (KDE warns about that when I have). I do have changed settings in /etc/kde/kdm/kdmrc, but it's mostly the background and the default selected user. The only setting that may be relevant is: BootManager=Grub But according to the comments above the option it's only used when choosing shutdown from KDM itself, not KDE. It may be propagated to KDE though.
BootManager=Grub does not make sense: If anything, it should be Grub2, but we don't really support that; in particular, it doesn't work with SELinux enabled (by design), see bug #902014.
Yeah, probably a leftover from a previous upgrade. I reverted it back to None and I still hit the timeout on kdm.service shutdown.
If there's a problem with the service's stopping, is it reproducible if you try to stop it manually? (systemctl stop kdm.service) If it is, please do the following as root: 1) edit /usr/lib/systemd/system/kdm.service and change the line "ExecStart=/usr/bin/kdm vt1" to "ExecStart=/usr/bin/kdm -debug 0x08F vt1" 2) systemctl stop kdm.service ; systemctl --system daemon-reload ; rm /var/log/kdm.log ; systemctl start kdm.service # this restarts KDM and deletes the old log 3) systemctl stop kdm.service And post the /var/log/kdm.log here. Thank you.
I'll post the file here right now. Please note that: - I've started KDM, logged in, logged out, and stopped KDM - I've added lines starting with "[MARKER]" in the log to tell what I was doing - I do NOT get the timeout if I dont actually log in. If I just start and stop KDM it stops immediately - I've set the KDM timeout to 20s as you'll see at the bottom of the log. Thanks !
Created attachment 703720 [details] KDM debug log
Hi, umm, are you sure you're using Fedora? :) We don't start DMs on VT7 for... quite a while. Have you done anything about the setting? Is the line you were changing in /usr/lib/systemd/system/kdm.service really ending with "vt1"? It seems really strange it's starting on vt7... Thank you.
Yeah, it usually starts on VT1 and has been for a while. But after a few stops and starts I did for testing and getting the logs, at some point it started on VT7. I don't think it changes much about the problem at hand here (but I understand your surprise :-) )
Yes, yes, it seems so. Well, as I'm quite clueless why it's being stuck there. I suspect it's waiting for something, though, like some NFS operation or such. Could you please provide output of the following command run while you're waiting on the timeout? And the logs, once again. pstree -aAcGglnpu Thank you.
OK, progress. I think I found the culprit. I'm using pam_ssh, and the ssh-agent is not killed on logout. I can see that from the output of systemctl status kdm after logging out. If I try to kill it manually, nothing happens, only a SIGKILL makes it go away. Here's the content of my /etc/pam.d/kdm: auth [success=done ignore=ignore default=bad] pam_selinux_permit.so auth required pam_env.so auth sufficient pam_ssh.so try_first_pass keyfiles=id_dsa,id_rsa,identity,id_rsa.fedora auth substack system-auth #-auth optional pam_gnome_keyring.so auth include postlogin account required pam_nologin.so account include system-auth password include system-auth session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so -session optional pam_ck_connector.so session required pam_selinux.so open session optional pam_keyinit.so force revoke session required pam_namespace.so session optional pam_ssh.so session include system-auth #-session optional pam_gnome_keyring.so auto_start session include postlogin If I remove the calls to pam_ssh.so in auth and session, I don't hit the timeout anymore. Do you have any idea what is causing ssh-agent to hang ? It does work when I'm logged in (I don't enter my passphrase, which is the same as my login password).
*** Bug 920538 has been marked as a duplicate of this bug. ***
There is an entry related to this in bugzilla.novell.com: https://bugzilla.novell.com/show_bug.cgi?id=727246 the second comment is: The easiest way to solve this problem is to clear the signal mask either in ssh-agent (when started) or in pam_ssh (before executing ssh-agent). I like the second option a bit more, I'll add the patch in a few minutes. they also propose a patch (used in suse linux)
Thank you. Will look at it on the KDM side and then decide if the patch is reasonable.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.