Hide Forgot
Description of problem: After the update to gnome-keyring I always get a warning at the first line when using svn. WARNING: couldn't connect to: /tmp/keyring-xxxx/pkcs11: No such file or directory Version-Release number of selected component (if applicable): gnome-keyring-3.2.1-3.fc16.x86_64 How reproducible: always Steps to Reproduce: 1. svn co http://.... 2. Warning is shown 3. svn ci http://... 4. Warning is shown Actual results: WARNING: couldn't connect to: /tmp/keyring-xxxxx/pkcs11: No such file or directory Expected results: No warning should be shown. Additional info: Deleting /etc/pkcs11/modules/gnome* works as work-a-round
Happens with starting different programs, e.g. LibreOffice. Seems to be fixed upstream: https://bugzilla.gnome.org/show_bug.cgi?id=665961
(In reply to comment #1) > Happens with starting different programs, e.g. LibreOffice. > Seems to be fixed upstream: > https://bugzilla.gnome.org/show_bug.cgi?id=665961 This patch has been pushed in gnome-keyring-3.2.1-3.fc16, apparently more work is needed.
I have gnome-keyring-3.3.4-2.fc17.x86_64 and I'm seeing this warning on every non-root libvirt client access. A simple reproducer is: $ virsh -c qemu:///system list WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-S31tpg/pkcs11: No such file or directory Id Name State ----------------------------------
In my environment I see: GNOME_KEYRING_CONTROL=/tmp/keyring-khCs9S GNOME_KEYRING_PID=1242 but no process 1242 or /tmp/keyring-khCs9S directory.
(In reply to comment #4) > but no process 1242 or /tmp/keyring-khCs9S directory. Were there any logged crashes for the gnome-keyring-daemon?
(In reply to comment #5) > (In reply to comment #4) > > but no process 1242 or /tmp/keyring-khCs9S directory. > > Were there any logged crashes for the gnome-keyring-daemon? Not here. Also the keyring daemon is running: 1813 ? Sl 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login 2357 ? S 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets so it seems unlikely that it has crashed.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > but no process 1242 or /tmp/keyring-khCs9S directory. > > > > Were there any logged crashes for the gnome-keyring-daemon? > > Not here. Also the keyring daemon is running: > > 1813 ? Sl 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login > 2357 ? S 0:00 /usr/bin/gnome-keyring-daemon --start --foreground > --components=secrets > > so it seems unlikely that it has crashed. It may have respawn automatically by another incoming request. If the env. var was originally set by a running daemon, there must have been a reason for it to quit/crash. Could you maybe watch for gnome-keyring-daemon PIDs how they change when you actually use them? (e.g. by using svn or virsh)
They don't appear to change: $ ps ax | grep gnome-key 1813 ? Sl 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login 2357 ? S 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets 16469 pts/11 S+ 0:00 grep --color=auto gnome-key $ virsh -c qemu:///system list WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-e3wrUm/pkcs11: No such file or directory Id Name State ---------------------------------- $ ps ax | grep gnome-key 1813 ? Sl 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login 2357 ? S 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets 16475 pts/11 S+ 0:00 grep --color=auto gnome-key
(In reply to comment #5) > (In reply to comment #4) > > but no process 1242 or /tmp/keyring-khCs9S directory. > > Were there any logged crashes for the gnome-keyring-daemon? I can't find any.
I have this same message when I start vnc (maybe too when I ssh) but I have no gnome-keyring-daemon running. I only use gdm to login via the "user script" option,
BTW - I'm running kde/kdm
(In reply to comment #2) > This patch has been pushed in gnome-keyring-3.2.1-3.fc16, apparently more work > is needed. I see that libgnome-keyring is still at 3.2.0 (libgnome-keyring-3.2.0-1.fc16). Could the problem be caused by programs using the unpatched library?
(In reply to comment #12) > (In reply to comment #2) > > > This patch has been pushed in gnome-keyring-3.2.1-3.fc16, apparently more work > > is needed. > > I see that libgnome-keyring is still at 3.2.0 (libgnome-keyring-3.2.0-1.fc16). > Could the problem be caused by programs using the unpatched library? I'm using libgnome-keyring-3.3.4-1.fc17.x86_64 and seeing this bug.
Hello, I am seeing the same problem using libgnome-keyring-3.2.0.fc16 (as mentioned above). Any news about this bug?
Still there with: gnome-keyring-3.2.1-3.fc16 libgnome-keyring-3.2.0-1.fc16 I'm about to change my login config files to unset GNOME_KEYRING_CONTROL and GNOME_KEYRING_PID, which at least makes the message go away.
Same here. I get this annoying message all the time (mutt, openoffice, others) gnome-keyring-3.2.1-3.fc16.x86_64 libgnome-keyring-3.2.0-1.fc16.x86_64
I use KDE, but warning there is (konsole session) [sergeil@homedesk work]$ svn update WARNING: couldn't connect to: /tmp/keyring-XBSeu2/pkcs11: Нет такого файла или каталога
I'm now experiencing this problem after recently switching from Gnome to KDE on my Fedora laptop. Whenever I run SVN, I got the error. I did some research and found this seems to be a problem with the /etc/xdg/autostart/gnome-keyring-*.desktop file, specifically the OnlyShowIn paramter. I took a look at my /etc/xdg/autostart/gnome-keyring-pkcs11.desktop file and found this: OnlyShowIn=GNOME;LXDE;XFCE;Unity KDE was missing so I added it: OnlyShowIn=GNOME;LXDE;XFCE;Unity;KDE Then I rebooted, ran SVN, and the error did not appear. Seems like the problem only affects KDE users (or any users not using desktop environments specified in OnlyShowIn). Hope this helps.
Well, some of us don't run any "desktop environment", just a simple window manager. Maybe we'd need to add XDM,XINIT or XSESSION to OnyShowIn above, but that seems to start a daemon that I could be wrong but I don't think I need.
Any chance of fixing this? I notice it also affects lpr/lpq.
It seems there may be several things interacting here. I fixed the problem by updating the gnome login keyring password to my current password as it had gotten out of sync with my system login password. Now gnome-keyring-daemon is running fine. In my case (KDE) the keyring is started via /etc/pam.d/kdm: -auth optional pam_gnome_keyring.so -session optional pam_gnome_keyring.so auto_start Some questions I have: - Should the gnome-keyring-daemon be exiting if it cannot unlock the login keyring? - If it should be exiting, perhaps pam_gnome_keyring should not be setting the GNOME_KEYRING_* environment variables in that case. I'll try to test with F17 to see what is the status there. I would simply delete the gnome keyring (~/.gnome2/keyrings/login.keyring) but it appears that abrt uses it (and only it).
(In reply to comment #20) > Any chance of fixing this? I notice it also affects lpr/lpq. I'm seeing this error relatively often, and it's currently affecting my lpstat. #lpstat -r WARNING: couldn't connect to: /tmp/keyring-33dWEd/pkcs11: No such file or directory scheduler is not running Whereas cupsd is actually running. #ps -eaf | grep cupsd root 1042 1 0 May07 ? 00:00:02 /usr/sbin/cupsd -f olsam 11134 8032 0 21:04 pts/0 00:00:00 grep --color=auto cupsd I'm using KDE, so I'm not entirely sure why the gnome keyring is being accessed instead of KWallet. Any tips on a workaround? Any idea when this will be hit FC16?
I'm also seeing this in 32bit FC16.
(In reply to comment #22) > (In reply to comment #20) > > Any chance of fixing this? I notice it also affects lpr/lpq. > > I'm seeing this error relatively often, and it's currently affecting my lpstat. > > #lpstat -r > WARNING: couldn't connect to: /tmp/keyring-33dWEd/pkcs11: No such file or > directory > scheduler is not running On F17, the behaviour is like this (I cannot print directly to printers connected to this computer, but the rest of my family can): $ lpstat -r WARNING: gnome-keyring:: couldn't connect to: /run/user/nicku/keyring-NpYysJ/pkcs11: No such file or directory scheduler is running $ ll /run/user/nicku/ total 0 drwx------. 2 nicku nicku 60 May 10 07:27 dconf dr-x------. 2 nicku nicku 0 May 7 15:56 gvfs drwx------. 2 nicku nicku 60 May 9 22:46 keyring-qDM1M7 lrwxrwxrwx. 1 root root 17 May 7 15:56 X11-display -> /tmp/.X11-unix/X0 $ ll /run/user/nicku/keyring-qDM1M7 total 0 srwxr-xr-x. 1 nicku nicku 0 May 9 22:46 control Could this be related to running Xfce?
Same problem here, with F16 and F17 (both with all updates installed). And yes, I'm running FVWM2 instead of Gnome or similar. Either gnome-keyring-daemon should only be started in environments it is working with, or the entry OnlyShowIn=GNOME;LXDE;XFCE;Unity; is way too restrictive.
Same here with 2 F17 systems. I'm running openbox on both systems.
I'm having the same problem in Fedora 17. I do NOT use Gnome or KDE (I use my own window manager), and /usr/bin/gnome-keyring-daemon is NOT running - why should it? When I run lpq, svn commit, or many other programs, I get messages like: WARNING: gnome-keyring:: couldn't connect to: /run/user/nyh/keyring-QGs7ct/pkcs11: No such file or directory I checked, and I actually have the following environment variables set: GNOME_KEYRING_CONTROL=/run/user/nyh/keyring-QGs7ct GNOME_KEYRING_PID=7752 I have no idea where they came from. Very odd...
See comment #18 for a workaround
Rex: And what is that one is supposed to add to OnlyShowIn if one runs "user script" session?
And in any case, that workaround is fundamentally broken - it simply causes me to run this gnome-keyring-daemon, which I shouldn't want to run if I don't use Gnome. Any I also wonder why GNOME_KEYRING_CONTROL/PID is set at all on my system (with "user script" session) - who sets them?
There is also a workaround in the description: delete /etc/pkcs11/modules/gnome* I know - it's quick 'n dirty but it works on my systems.
> And what is that one is supposed to add to OnlyShowIn if one runs "user script" session? I just tried adding unset GNOME_KEYRING_PID unset GNOME_KEYRING_CONTROL to my .xsession. Seems to work fine! It's still only a workaround, but not a too dirty one IMHO.
For persons like me who actually want to use the gnome-keyring-daemon without gnome, you need to launch something like this : eval `/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh,gpg` Make sure it is launched after the dbus-daemon (which I do believe is started from /etc/X11/xinit/xinitrc.d/00-start-message-bus-sh) and before you start your window manager. For persons who don't want to use the gnome-keyring-daemon, I think you should remove any mention of pam_gnome_keyring.so in /etc/pam.d/* (not tested). This is not directly related, but there are some useful informations about how the gnome-keyring-daemon is started here : https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/357346/comments/5
Seeing this on Fedora 17 with KDE. First noticed when running "lpstat", but other apps print the error as well. My exact error message was: WARNING: gnome-keyring:: couldn't connect to: /run/user/brf/keyring-Mtg7v7/pkcs11: No such file or directory The /run/user/brf/keyring-Mtg7v7 directory doesn't exist. The two GNOME_KEYRING environment variables are set, but the daemon isn't running.
(In reply to comment #33) > For persons like me who actually want to use the gnome-keyring-daemon > without gnome, you need to launch something like this : > > eval `/usr/bin/gnome-keyring-daemon --start > --components=pkcs11,secrets,ssh,gpg` > > Make sure it is launched after the dbus-daemon (which I do believe is > started from /etc/X11/xinit/xinitrc.d/00-start-message-bus-sh) and before > you start your window manager. > > For persons who don't want to use the gnome-keyring-daemon, I think you > should remove any mention of pam_gnome_keyring.so in /etc/pam.d/* (not > tested). > > > This is not directly related, but there are some useful informations about > how the gnome-keyring-daemon is started here : > https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/357346/comments/ > 5 I think this is very related because it explains the 2-step start process for gome-keyring. If there is GOME_KEYRING_* in the env but no daemon running then the first step (--login) happened (presumably through pam) but the second step (--start) either didn't happen at all (because the non-gnome desktop environment did not invoke step 2 of gnome-keyring) or didn't succeed. Now, there still might be also a bug where pam tries to invoke step 1 and fails (e.g. because the login password and the gnome keyring password differ) but sets the environment variables nonetheless. So, the same symptoms may indicate several causes. (For KDE land: KDM needs to do phase 1 if it wants to start Gnome the same way as GDM does. Does phase 2 happen when KDM starts KDE?)
I'd always assumed step 1 was pam init'd via DM (be it gdm or kdm or whatever), and step 2 was the /etc/xdg/autostart stuff spawned by your DE of choice. If correct, we're still back to the failure of gnome-keyring to handle the case of those autostart'd items not running due to restrictive: OnlyShowIn=GNOME;Unity; in their .desktop files. So, at least 2 ways forward as I see it: 1. make gnome-keyring handle this case more gracefully, and not spew the error/warning .../.cache/keyring-xyQAcY/pkcs11: No such file or directory which seems to be what the upstream https://bugzilla.gnome.org/show_bug.cgi?id=665961 bug is about (well, *was*, since it is closed and claimed fixed). or 2. adjust the gnome-keyring autostart files to remove the strictive OnlyShowIn= key for at least /etc/xdg/autostart/gnome-keyring-pkcs11.desktop (maybe more). I'd be more than happy to help implement the relatively-easy option 2. I'd even be willing to implement a hammer for option 1, to suppress the error output, but that may be less appealing for some (and possibly hide real errors that ought to be printed).
hrm, i'm beginning to wonder if there's some dbus activation going on too, which may or may not complicate matters (especially if the dbus-activated items are expected to be able to set/modify environment variables as has been hinted).
OK, looks like upstream has opted for 1, am working in the upstream bug on a patch
Here's the work-in-progress patch we have so far, http://bugzilla-attachments.gnome.org/attachment.cgi?id=221615 Doesn't cover everything to upstream's satisfaction for inclusion yet, but it certainly better than the status quo. I'd suggest we include it in our packaging for testing and feedback in the meantime. If ACK'd, I'm volunteering to do the packaging work and issue -testing updates
gnome-keyring-3.6.1-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/gnome-keyring-3.6.1-2.fc18
gnome-keyring-3.2.2-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/gnome-keyring-3.2.2-2.fc16
gnome-keyring-3.4.1-4.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/gnome-keyring-3.4.1-4.fc17
Package gnome-keyring-3.2.2-2.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnome-keyring-3.2.2-2.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17969/gnome-keyring-3.2.2-2.fc16 then log in and leave karma (feedback).
gnome-keyring-3.6.1-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
gnome-keyring-3.4.1-4.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
gnome-keyring-3.2.2-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Sadly, after the update both Firefox and Chromium no longer use the keyring for the passwords... How to switch that on again?
(In reply to comment #47) > Sadly, after the update both Firefox and Chromium no longer use the keyring > for the passwords... How to switch that on again? Update: it sometimes works, sometimes not (I rebooted a few times since yesterday to test).