- Package:
- gnome-keyring
- Source:
- gnome-keyring
- Description:
- GNOME keyring services (daemon and tools)
- Submitter:
- OGAWA Hirofumi
- Date:
- 2017-09-16 08:36:03 UTC
- Severity:
- normal
Hi,
When I start gnome-session (not sure if startx is important to
reproduce) by
$ startx
Current gnome-keyring has the race with org.gnome.SessionManager
initialization of gnome-session. Because dbus doesn't seem to make the
name available to others immediately.
The sequence of the race is:
gnome-session gnome-keyring
.SessionManager init
run autostart apps
start by autostart
call .SessionManager.Setenv
call .SessionManager.ClientPrivate
.SessionManager available
This race becomes the cause of random Setenv failure for SSH_AUTH_SOCK
for example like following.
** Message: couldn't register in session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
To fix this, the attached patch starts to watch .NameOwnerChanged before
calling .SessionManager. With this, if .SessionManager is not available
yet, callings are done via .NameOwnerChanged notification.
Then, after makes sure calling of .SessionManager was done, this
removes watch of .NameOwnerChanged.
Please update to gnome-keyring 3.20.0-1 and report back whether this fixes your bug. gnome-keyring 3.20 fixed https://bugzilla.gnome.org/738205 (Despite the bug title, it wasn't limited to just Wayland sessions). Thanks, Jeremy Bicha
Please update to gnome-keyring 3.20.0-1 and report back whether this fixes your bug. gnome-keyring 3.20 fixed https://bugzilla.gnome.org/738205 (Despite the bug title, it wasn't limited to just Wayland sessions). Thanks, Jeremy Bicha
Jeremy Bicha <jbicha@linux.com> writes: At least for now, this bug is not reproduced. So it would be better to close the bug. If reproduced, I will re-open. Thanks.
Jeremy Bicha <jbicha@linux.com> writes: At least for now, this bug is not reproduced. So it would be better to close the bug. If reproduced, I will re-open. Thanks.
Jeremy Bicha <jbicha@linux.com> writes: At least for now, this bug is not reproduced. So it would be better to close the bug. If reproduced, I will re-open. Thanks.
Hello! I was struck by this issue pretty consistently while using 3.20.0-1 (but did not run into it in earlier versions, classical race issue it seems). The problems went away for me when applying the patch in this bug report. I've been trying to get a hold off stefw to discuss your patch but haven't succeded reaching him. This issue (and the patch) should be forwarded to the upstream bugzilla..... Regards, Andreas Henriksson
On Mon, 13 Jun 2016 08:55:23 +0200 Andreas Henriksson <andreas@fatal.se this (but seems). sessions). to Hi, I am occasionally seeing the same problem since I upgraded to Stretch a few months ago. I am using Gnome (gnome-keyring 3.20.0-3) with Xorg. $ echo $SSH_AUTH_SOCK /tmp/ssh-3ymBpl68cNYk/agent.2019 $ dbus-send --session --dest=org.gnome.keyring --print-reply /org/gnome/keyring/daemon org.gnome.keyring.Daemon.GetEnvironment method return time=1505550164.345498 sender=:1.25 -> destination=:1.636 serial=10249 reply_serial=2 array [ dict entry( string "SSH_AUTH_SOCK" string "/run/user/1000/keyring/ssh" ) ] $ ps aux | grep gnome-keyring luca 2000 0.3 0.0 299844 21224 ? SLl 08:37 0:09 /usr/bin/gnome-keyring-daemon --daemonize --login $ ssh-add -L The agent has no identities. $ SSH_AUTH_SOCK=/run/user/1000/keyring/ssh ssh-add -L ssh-rsa AAAAB3 <cut> Kind regards, Luca Boccassi