GNOME Bugzilla – Bug 679892
gnome-keyring-daemon does not start
Last modified: 2012-07-18 06:02:22 UTC
Description: . gnome-keyring-daemon is not started by pam_gnome_keyring.so (unless auth type argument for pam_gnome_keyring.so is "auto_start" and the login keyring password is incorrect) gnome-keyring 3.4.1-2 pam 1.1.5-4 The details are at https://bbs.archlinux.org/viewtopic.php?id=144783
More precisely, login (bin/login, pam_gnome_keyring.so, entire pam stack, ???) sends SIGTERM to gnome-keyring-daemon before exiting/replaced by agetty.
Perhaps login closes the pam session? See pam_sm_close_session() in pam/gkr-pam-module.c. I have not tested the pam module and gnome-keyring-daemon with console logins. This isn't a typical use case. That said, if you do discover the source of the problems, I would be happy to review and (if everything is in order) commit related patches. I'm also available on #keyring at gimpnet irc to help you troubleshoot or give advice if you want to work on this. However I'm not able to invest a lot of my own time working on this.
I can guarantee the shutdown has nothing to do with stop_daemon::gkr-pam-module.c or gkd_main_quit::gkd-main.c. Also I made a mistake, the signal is SIGHUP not SIGTERM. The solution is to stop gnome-keyring-daemon from responding to SIGHUP, but this is like swatting a fly with a baseball bat. I don't understand the root of the problem: in my strace I don't understand how gkd receives SIGHUP, nor can I find any code in login.c (util-linux) that sent it. For more information read https://bbs.archlinux.org/viewtopic.php?pid=1129407#p1129407 onwards. Also, I'm on irc. -Thanks.
Created attachment 219045 [details] [review] patch: if(run_daemonized) call setsid() before second fork()
patch: if(run_daemonized) call setsid() before second fork() I'm not sure how a session leader process dies during login, but in any case setsid() is canonical behavior when forking a daemon. And it fixes this bug.
Comment on attachment 219045 [details] [review] patch: if(run_daemonized) call setsid() before second fork() I'm not sure how a session leader process dies during login, but in any case setsid() is canonical behavior when forking a daemon. And it fixes this bug.
just to be clear, this means that gnome-keyring-daemon probably won't be stopped when sending SIGHUP as root to /bin/login, as setsid implies a new process group as well.
Thanks. I've added a proper git commit message and your author info, and pushed this to git master with some formatting changes.