Red Hat Bugzilla – Bug 690586
sugar-desktop gnome-keyring-pam-2.91.93-1.fc15 (i686) does not work-pops up 11 times
Last modified: 2015-03-03 17:59:15 EST
Description of problem:
Unlock Login Keyring pops up: pops up 11 times before sugar-desktop enters F3 main window. (On switching to f1 network neighborhood, wireless Access point is already connected.)
Version-Release number of selected component (if applicable):
sugar 0.92.0 Fedora release 15 (Lovelock)
start sugar-desktop in sugar-emulator or from gdm switcher
Steps to Reproduce:
1.keychain to work
11 pop ups
keychain to be accessed on first try
https://bugzilla.redhat.com/show_bug.cgi?id=649013 earlier duplicate?
can you please provide more information in which way the tool keychain is involved?
I am not confident that keychain is even part of your setup. You write yourself about gnome-keyring-pam-2.91.93-1.fc15 and the description itself sounds as if the gnome keyring access is what misbehaves.
Else, how is your keychain configured?
When I log in to gnome3 (f15), my password is required to log in by gdm. (I assume that the keychain which is installed retains my password.) when sugar-desktop starts from (xepyr / sugar-emulator) that password seems to be not accessible, or written to, and I get 11 repeated pop-ups requesting my password even though I have entered the correct password. when the pop-ups finish, sugar desktop works normally.
keychain is an extra tool which is not installed automatically. So please check by
rpm -q keychain
whether you really have it installed. keychain even is an opt-in tool, which means you must actively activate its use by creating a valid ~/.keychainrc. So can you please verify and post your ~/.keychainrc as well?
rpm -q keychain
package keychain is not installed
you were right
yum install keychain
keychain.noarch 0:2.6,8-8.fc15 will be installed
rpm -q keychain
same 11 pop-ups
Do I need to do something else to get this fixed?
Ok, so I understand from your last comment #4 that keychain was NOT installed. Thus it can not be the cause of your isse.
I close this ticket assigned to keychain as this is not the application giving you problems. You may reopen a ticket for a more appropriate package, which may be gnome-keyring.
reassigned to gnome-kering
I am not package owner of gnome-keyring
So, if the Sugar session was started from Xnest/Xephyr, it's highly probable that the keyring is still locked. Due to that fact, it asks for a password, probably on every request, thus you're seeing those 11 prompts. It could be anything, most probably NetworkManager or some app that autoruns.
I admit it would be nice to show the prompt only once and block the other requests. I think I've seen a bug for that somewhere...
For hints about running gnome-keyring-daemon, please see http://live.gnome.org/GnomeKeyring/RunningDaemon
typing # gnome-keyring-daemon --start:
** Message: couldn't access control socket? /tmp/keyring-xxxxx/control: Permission denied.
** Message: couldn't connect to dbus session bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Is there an incompatibility with sugar-emulator and the dbus?
(In reply to comment #8)
> So, if the Sugar session was started from Xnest/Xephyr, it's highly probable
> that the keyring is still locked. Due to that fact, it asks for a password,
> probably on every request, thus you're seeing those 11 prompts. It could be
> anything, most probably NetworkManager or some app that autoruns.
Its telepathy-mission-control which uses it to store account information.
> I admit it would be nice to show the prompt only once and block the other
> requests. I think I've seen a bug for that somewhere...
> For hints about running gnome-keyring-daemon, please see
We fixed the issue on the live image by creating a default keyring with the following bash scriptlet. When we install and a new user is created this script obviously doesn't run (such as a user with liveinst). I'm not sure how other desktops create a new keyring for a user if one doesn't exist. Is that documented anywhere? It might be possible to put a default keyring in /etc/skel/
if [ ! -e /home/liveuser/.gnome2/keyrings/login.keyring ]; then
mkdir -p /home/liveuser/.gnome2/keyrings
cat >> /home/liveuser/.gnome2/keyrings/login.keyring << FOE
chown -R liveuser:liveuser /home/liveuser/.gnome2/keyrings
will be fixed in sugar live image for f-15