Bug 454186

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.

$ gnome-keyring-daemon
** Message: another SSH agent is running at: /tmp/keyring-XZf6Tg/ssh
GNOME_KEYRING_SOCKET=/tmp/keyring-SR9ZYj/socket
SSH_AUTH_SOCK=/tmp/keyring-SR9ZYj/ssh
GNOME_KEYRING_PID=17745

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
   SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
   SSH_AUTH_SOCK=/tmp/keyring-y0Zso0/ssh

   > fuser $SSH_AUTH_SOCK
     2674
   > 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
   SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
   SSH_AUTH_SOCK=/tmp/keyring-y0Zso0/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).


--
Ian

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>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0x00000032b3432f05 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#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>)
    at gtestutils.c:1301
#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)
    at gkr-keyring.c:504
#5  0x000000000040bdf9 in lock_each_keyring (keyring=0x14ff, unused=0x1519)
    at gkr-daemon-ops.c:722
#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>)
    at gkr-daemon-io.c:298
#9  0x0000000000430aba in async_worker_thread (data=<value optimized out>)
    at gkr-async.c:269
#10 0x0000003c69260d44 in g_thread_create_proxy (data=0x136e0b0)
---Type <return> to continue, or q <return> to quit---
    at gthread.c:635
#11 0x00000032b40073da in start_thread (arg=<value optimized out>)
    at pthread_create.c:297
#12 0x00000032b34e62bd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
(gdb) c
Continuing.
[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.