Red Hat Bugzilla – Bug 454186
gnome-keyring-daemon dies during hibernation
Last modified: 2015-03-03 17:32:55 EST
Description of problem:
After resume from either suspend or hibernate, seahorse agent does not ask for
keyring password, so for instance to commit to Fedora cvs I have to enter the
ssh keys password a few times. Before the resume a window pops out and the
password is required only once.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. suspend/hibernate the machine
3. do something that requires entering ssh key password
password prompt appears in the console every time ssh key is needed
a window pops out and asks for password only once
I don't know if it's related, but ssh-add does not work either (says “Could not
open a connection to your authentication agent.”), so there is really no way to
avoid the need for entering the password several times, apart from reboot.
I think you need to do something that requires entering ssh key password before suspend as well.
Erm, it is still present with Fedora 10. After thorough testing, I found out that this bug is only triggered by hibernation, and that you don't have do to anything prior to it. Do I need to say it makes hibernation pretty much useless, since once you resume you need to input your keyring password every time? Imagine updating a package in cvs like that...
This is a somewhat confused bug report.
If you are talking about ssh, seahorse is not involved, gnome-keyring-daemon is acting as ssh agent.
** Message: another SSH agent is running at: /tmp/keyring-XZf6Tg/ssh
This is what happens if I try to start gnome-keyring-daemon manually after waking up from hibernation.
On the other hand, gnome-keyring-daemon does not show up in the list of running processes.
Possibly related to this - gnome-keyring-daemon *sometimes* dies if left running overnight. For example yesterday afternoon I had this:
> set | grep SSH
> fuser $SSH_AUTH_SOCK
> ps h `fuser $SSH_AUTH_SOCK`
2674 ? S 0:37 /usr/bin/gnome-keyring-daemon -d --login
All working nicely. This morning I got:
> set | grep SSH
> fuser $SSH_AUTH_SOCK
which means the gnome-keyring-daemon process has died.
It seems like the process dies (or is killed) when the screensaver is unlocked in the morning rather than during the night. (screensaver unlock doesn't always do that though).
I checked with gdb and got the following:
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f68bc4f4950 (LWP 5401)]
0x00000032b3432f05 in raise (sig=<value optimized out>)
64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
#0 0x00000032b3432f05 in raise (sig=<value optimized out>)
#1 0x00000032b3434a73 in abort () at abort.c:88
#2 0x0000003c6925d803 in IA__g_assertion_message (domain=0x3c692b72fe "",
file=0x453b0b "gkr-keyring.c", line=<value optimized out>,
func=0x453cd0 "gkr_keyring_lock", message=<value optimized out>)
#3 0x0000003c6925dca2 in IA__g_assertion_message_expr (domain=0x0,
file=0x453b0b "gkr-keyring.c", line=504, func=0x453cd0 "gkr_keyring_lock",
expr=<value optimized out>) at gtestutils.c:1312
#4 0x000000000043eac9 in gkr_keyring_lock (keyring=0x13715f0)
#5 0x000000000040bdf9 in lock_each_keyring (keyring=0x14ff, unused=0x1519)
#6 0x0000000000442a59 in gkr_keyrings_foreach (
func=0x40bdf0 <lock_each_keyring>, data=0x0) at gkr-keyrings.c:389
#7 0x000000000040da20 in op_lock_all (packet=<value optimized out>,
result=0x136a440, req=0x6) at gkr-daemon-ops.c:730
#8 0x000000000040b93a in client_worker_main (user_data=<value optimized out>)
#9 0x0000000000430aba in async_worker_thread (data=<value optimized out>)
#10 0x0000003c69260d44 in g_thread_create_proxy (data=0x136e0b0)
---Type <return> to continue, or q <return> to quit---
#11 0x00000032b40073da in start_thread (arg=<value optimized out>)
#12 0x00000032b34e62bd in clone ()
[Thread 0x7f68bc4f4950 (LWP 5401) exited]
Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
I'm not sure how useful it is, though.
I've found that the keyring-daemon dies unpredictably. I've had it die a few minutes after login but mostly after longer periods. Sometimes it will run for days before dying and on rare occasions gets through an entire working week without a failure.
Looks like it finally works in Fedora 11.