Bug 454186 - gnome-keyring-daemon dies during hibernation
gnome-keyring-daemon dies during hibernation
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-keyring (Show other bugs)
10
All Linux
low Severity low
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-06 05:15 EDT by Julian Sikorski
Modified: 2015-03-03 17:32 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-28 14:26:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Julian Sikorski 2008-07-06 05:15:54 EDT
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):
2.22.2-1.fc9

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 13:35:07 EDT
I think you need to do something that requires entering ssh key password before suspend as well.
Comment 2 Julian Sikorski 2008-11-26 01:45:51 EST
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 14:18:07 EST
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 06:46:54 EST
$ 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.
Comment 5 Julian Sikorski 2009-01-13 07:33:24 EST
On the other hand, gnome-keyring-daemon does not show up in the list of running processes.
Comment 6 Ian Mortimer 2009-02-04 21:26:23 EST
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
Comment 7 Julian Sikorski 2009-02-18 04:05:46 EST
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.
Comment 8 Ian Mortimer 2009-02-18 16:28:57 EST
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 14:26:45 EDT
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.