Bug 913820

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.