Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 454186 - gnome-keyring-daemon dies during hibernation
Summary: gnome-keyring-daemon dies during hibernation
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-keyring
Version: 10
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tomáš Bžatek
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-06 09:15 UTC by Julian Sikorski
Modified: 2015-03-03 22:32 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-07-28 18:26:45 UTC

Attachments (Terms of Use)

Description Julian Sikorski 2008-07-06 09:15:54 UTC
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):

How reproducible:
every time

Steps to Reproduce:
1. suspend/hibernate the machine
2. resume
3. do something that requires entering ssh key password
Actual results:
password prompt appears in the console every time ssh key is needed

Expected results:
a window pops out and asks for password only once

Additional info:
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.

Comment 1 Julian Sikorski 2008-08-19 17:35:07 UTC
I think you need to do something that requires entering ssh key password before suspend as well.

Comment 2 Julian Sikorski 2008-11-26 06:45:51 UTC
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...

Comment 3 Matthias Clasen 2008-12-13 19:18:07 UTC
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.

Comment 4 Julian Sikorski 2009-01-13 11:46:54 UTC
$ gnome-keyring-daemon
** 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.

Comment 5 Julian Sikorski 2009-01-13 12:33:24 UTC
On the other hand, gnome-keyring-daemon does not show up in the list of running processes.

Comment 6 Ian Mortimer 2009-02-05 02:26:23 UTC
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).


Comment 7 Julian Sikorski 2009-02-18 09:05:46 UTC
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
[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.

Comment 8 Ian Mortimer 2009-02-18 21:28:57 UTC
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.

Comment 9 Julian Sikorski 2009-07-28 18:26:45 UTC
Looks like it finally works in Fedora 11.

Note You need to log in before you can comment on or make changes to this bug.