gnome-keyring-daemon does not survive suspend/resume.

Bug #150432 reported by Brett Johnson
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-keyring (Ubuntu)
Invalid
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gnome-keyring

gnome-keyring-daemon is running before suspend, but is no longer running upon resume. Doesn't survive suspend to disk or ram.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug report. Does it create any use bug? What do you do and what error do you get exactly?

Changed in gnome-keyring:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Brett Johnson (linuxturtle) wrote :

Well, the keyring stores all kinds of useful information, like WPA/WEP keys, ssh key passphrases, etc.. The way I first noticed that the daemon wasn't running is that Network Manager couldn't just resume my wireless connection, but would always ask for the WAP's WPA passphrase (since it couldn't get it from the keyring). Same thing goes for using ssh (can't rely on the keyring to provide ssh-agent with the passphrase for the ssh key in question).

Revision history for this message
Sebastien Bacher (seb128) wrote :

Not confirming the bug. The keyring is locked on hibernate which is expected and works normally when entering the password on a new gutsy installation. Could you try to attach gdb to the keyring before using suspend and get a backtrace (http://wiki.ubuntu.com/DebuggingProgramCrash)?

Revision history for this message
Brett Johnson (linuxturtle) wrote :

Umm. Nevermind.

Turns out PIBKAC...

A while back, I changed /etc/defaults/acpi-support to restart dbus on resume, 'cause that was the only way I could get network-manager to resume itself. That was killing gnome-keyring-daemon as well as gnome-power-manager :o(

Sorry for the false alarm. My bad.

Changed in gnome-keyring:
status: Incomplete → Invalid
Revision history for this message
Peter Adolphs (futzilogik) wrote :

I get the same behaviour if I set HIBERNATE_MODE=platform in /etc/defaults/acpi-support. Can someone confirm this?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.