Launchpad has imported 10 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=454186.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2008-07-06T09:15:54+00:00 Julian wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- keyring/+bug/268141/comments/0 ------------------------------------------------------------------------ On 2008-08-19T17:35:07+00:00 Julian wrote: I think you need to do something that requires entering ssh key password before suspend as well. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- keyring/+bug/268141/comments/1 ------------------------------------------------------------------------ On 2008-11-26T06:45:51+00:00 Julian wrote: 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... Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- keyring/+bug/268141/comments/9 ------------------------------------------------------------------------ On 2008-12-13T19:18:07+00:00 Matthias wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- keyring/+bug/268141/comments/10 ------------------------------------------------------------------------ On 2009-01-13T11:46:54+00:00 Julian wrote: $ 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- keyring/+bug/268141/comments/11 ------------------------------------------------------------------------ On 2009-01-13T12:33:24+00:00 Julian wrote: On the other hand, gnome-keyring-daemon does not show up in the list of running processes. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- keyring/+bug/268141/comments/12 ------------------------------------------------------------------------ On 2009-02-05T02:26:23+00:00 Ian wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- keyring/+bug/268141/comments/28 ------------------------------------------------------------------------ On 2009-02-18T09:05:46+00:00 Julian wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- keyring/+bug/268141/comments/31 ------------------------------------------------------------------------ On 2009-02-18T21:28:57+00:00 Ian wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- keyring/+bug/268141/comments/32 ------------------------------------------------------------------------ On 2009-07-28T18:26:45+00:00 Julian wrote: Looks like it finally works in Fedora 11. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- keyring/+bug/268141/comments/33 ** Changed in: gnome-keyring (Fedora) Importance: Unknown => Low -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/268141 Title: no ssh-agent after resume from hibernate To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-keyring/+bug/268141/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
