gnome-keyring not unlocked on xenial when dbus-user-session is installed

Links to other users with the same or similar issue within the past 2 days:

https://askubuntu.com/questions/911877/chrome-and-chromium-are-taking-a-long-time-to-load

https://askubuntu.com/questions/913756/xubuntu-16-04-chrome-and-chromium-asking-for-keyring-i-want-this-right-not-del/913766

https://askubuntu.com/questions/912275/chrome-firefox-chromium-vivaldi-starts-up-slow-and-greys-out-online-passwords

Status changed to 'Confirmed' because the bug affects multiple users.

I'm not positive when an update was pushed out that caused this - my machine gets updates automatically every night but I rarely reboot. I rebooted yesterday and was immediately affected by it.

Here is another link with more users experiencing the same bug, while also noting that the CTRL-t shortcut to open terminal can take up to 2 minutes to start a new terminal session, which I am experiencing as well.

https://askubuntu.com/questions/898694/gnome-keyring-daemon-no-starting-up-properly

I'm also seeing slow startup in chrome/chromium, and gnome-terminal using keyboard shortcut.

When launching chromium-browser from command line I see the following messages:

Using PPAPI flash.
 --ppapi-flash-path=/usr/lib/adobe-flashplugin/libpepflashplayer.so --ppapi-flash-version=
[3823:3823:0513/140354.928952:ERROR:background_mode_manager_aura.cc(13)] Not implemented reached in virtual void BackgroundModeManager::EnableLaunchOnStartup(bool)
Gkr-Message: secret service operation failed: 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.
[3909:3909:0513/140445.076144:ERROR:interface_registry.cc(210)] Failed to locate a binder for interface: chrome::mojom::ResourceUsageReporter requested by: exposed by: via InterfaceProviderSpec "service_manager:connector".
Gkr-Message: secret service operation failed: 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.
[3823:3823:0513/140510.780378:ERROR:display_info_provider_aura.cc(31)] Not implemented reached in virtual void extensions::DisplayInfoProviderAura::UpdateDisplayUnitInfoForPlatform(const display::Display&, extensions::api::system_display::DisplayUnitInfo*)
Starting
[1:1:0513/140539.638655:ERROR:interface_registry.cc(210)] Failed to locate a binder for interface: chrome::mojom::ResourceUsageReporter requested by: exposed by: via InterfaceProviderSpec "service_manager:connector".

I'm also seeing slow response to taking a screenshot with shortcut keys.

This causes problems in other applications, too. I get constant requests from Evolution to enter my credentials (although they are stored in the keyring). The Nextcloud client asks for a(n actually stored) password as well.

All requests disappear if I start gnome-keyring-daemon manually from the command line.

vinagre is also affected, running gnome-keyring-daemon restores the normal behavior.

This askUbuntu answer actually fixed the issue cleanly https://askubuntu.com/a/911755/61218. The solution is adding a startup item with this commandline

    gnome-keyring-daemon --replace --foreground --components=secrets,ssh,pcks11

That is not a fix. It is a workaround. On boot, my system has gnome-keyring-daemon running which needs to be killed and restarted without --login in order to function. This was working a couple weeks ago. There should be no "fixes" the user need to do to regain this functionality.

Well, I mean workaround by "fix" word. This workaround is the shortest, cleanest and working think I've seen about this bug.

I've recently started getting this issue too. What is going on?? Ubuntu shouldn't be doing this on the LTS.

Sorry, I should have been more constructive with my comment. The workaround in #10 seems to partially work. It doesn't allow the "login" password keychain to be unlocked on login, but it at least let you see the passwords in seahorse so that it can be unlocked manually - which in turn prevents applications from hanging.

Status changed to 'Confirmed' because the bug affects multiple users.

I was wondering if there is anything I can to help regress the issue? Even if it is just trying to load various different older versions?

I use KeePass 2 on Mono so I'm not too bothered by this. Wifi and NetworkManager still have problems though.

On Google Chrome and likely Chromium I fixed the 2 minute start wait by adding --password-store=basic the command line. You can add it the Exec entry in your desktop file or by editing the menu entry with menu-libre or equivalent.

You will have to sign in to Chrome again if you use their syncing functionality. I like syncing because I can see history and open tabs from my phone on my desktop and vice versa.

It seems Chromium uses a plain text password store with the basic option so you may not prefer this option. I don't use Chromium password storage since I use KeePass so it works for me.

https://chromium.googlesource.com/chromium/src/+/lkcr/docs/linux_password_storage.md

I have read that PAM is supposed to unlock the keyring as configured in LightDM (My current display manager) but that's not being done apparently.

There is alot of garbage on Google about incompatibilities with autologin. My account is not set to autologin and requires a password to login.

Opera is also affected by this issue. Takes almost a minute to load whereas Firefox loads in under five seconds.

I have this problem too. With mysql-workbench, connecting to remote servers from file manager and other programs. The workaround from some upper posts restores functionality.

same for me here
by starting with the terminal

$google-chrome
[6136:6136:0528/125519.901742:ERROR:browser_main_loop.cc(279)] Gtk: Im Modulpfad »adwaita« konnte keine Themen-Engine gefunden werden,
[6136:6136:0528/125519.902002:ERROR:browser_main_loop.cc(279)] Gtk: Im Modulpfad »adwaita« konnte keine Themen-Engine gefunden werden,
Gkr-Message: secret service operation failed: 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.
Gkr-Message: secret service operation failed: 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.
[6136:6136:0528/125701.104195:ERROR:CONSOLE(0)] "Error in event handler for (unknown): TypeError: Cannot read property 'id' of undefined
    at inject_code (chrome-extension://mhcmfkkjmkcfgelgdpndepmimbmkbpfp/js/cs_inject.js:17:13)", source: https://www.google.de/_/chrome/newtab?espv=2&ie=UTF-8 (0)

after
$sudo apt install gnome-themes-standard

I got less error messages but still a long delay
$ google-chrome
Gkr-Message: secret service operation failed: 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.
Gkr-Message: secret service operation failed: 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.

from post #17 I tried this
$ google-chrome --password-store=basic

And the browser started immediately :-D

Same problem here:

Google-chrome is affected.
Skypeforlinux doesn't remember the password anymore
UnityMail is affected

I am having this problem as well to the point that I can't use my desktop. The only solution I have found is to install a different distro or version of Ubuntu other than 16.04.

Well, this bug also is affecting me, I used the workaround in #10 and it works, but I still need to put my password in order to unlock the "Login" Keyring (My system don't have autologin enabled btw), the weird thing is that this system is fresh installed (no more than a week) and It was working fine until today. Maybe there is some package that I installed yesterday that is affecting the system.
Google-chrome affected
Online accounts also is affected
I didn't test other apps, but as far I could check those apps were affected by this issue
Greetings

This also affects chromium-browser installed from Ubuntu repository.

What is odd is that it does not occur on all Ubuntu installations. I have a 2nd Ubuntu machine that does not suffer from this issue. What could possibly be different between a computer that exhibit this problem and another? I do not recall having played with any configuration file that relates to this issue.

Hans' observation that this is not impacting all of his machines is consistent with my experience of this issue. I have three Ubuntu machines and this is only impacting one of them. It is driving me nuts because the machine that is impacted is my main laptop. My server and my test machine which would be less of an issue to me as they don't get booted so often are working fine. A classic example of Murphy's Law.

Status changed to 'Confirmed' because the bug affects multiple users.

I agree with comments #25 and #26. It's likely a red herring, but this issue arose for me right after I installed the flatpak PPA and a pile of mono/M$ stuff. I still figure that those actions are orthogonal, but just in case everyone else recently installed similar stuff or a new PPA or...

I also had the flatpak PPA, I removed it but the situation didn't improve, I also reinstalled the gnome-keyring package with no luck.

This has manifested itself on a machine with a fresh install of 16.04.2 with nothing installed but google chrome. I have 2 other machines with this issue and neither have ever had the flatpak PPA enabled or anything installed from it.

I've installed the flatpak (and added the PPA) quite recently, but uninstalling the package didn't solve the issue for me.

Although chromium-browser is affected by the issue, it doesn't appear to be the cause of the issue itself (other apps like gnome-terminal appear to be similarly affected), so I'm marking this bug invalid for chromium-browser.

I am experiencing the same issue on one of my two machines. The 'Password and Keys' padlock icon next to 'Login' remains locked even with the correct password, and I'm unable to use Chrome, access e-mail etc..
I'm no expert but, in case it helps, these are two differences between the two machines I'm aware of...
- the machine with the problem has an encrypted installation and the other not. Otherwise both installations are similar (basic 16.04 and not much else)
- if I enter "ps aux | grep keyring" I get two 'gnome-keyring-daemon' processes listed on the problem machine (one for user 'lightdm' and one for myself), and only one on the machine without the problem (user is myself)
The machine with the problem is almost useless for the moment - would be great to get a solution.

The only "permanent" (well, it still asks for the password once when opening google-chrome after login) workaround I found was creating a startup item as described here: https://askubuntu.com/a/911896.

I uncovered another problematic side effect but I am unsure of the significance; perhaps this will trigger an idea for someone....

There are three user accounts on my box. Here's a flow:
1) Reboot box
2) Sign in as user 1
3) Examine running processes (as MikeD mentioned in #33) and observe two keyring processes
4) Log out as user 1
5) Log in as user 2
6) Observe that Unity (via upper-right corner power icon thing) shows two checkmarks indicating that both user 1 and user 2 are signed in

Maybe a clearer capture of something amiss... logging in and out and in repeatedly causes the keyring daemon process to be started again and again (as lightdm and as the user). Please see attached.

On my machine I'm unable to get any of the above workarounds to unlock the keyring. Entering...
gnome-keyring-daemon --replace --foreground --components=secrets,ssh,pcks11
...ends in the terminal hanging at "SSH_AUTH_SOCK=/run/user/1000/keyring/ssh".

The following seems to have got me running normally again. Working on the theory the keyring file was somehow corrupted, I deleted the keyring file...
rm ~/.local/share/keyrings/login.keyring
...and rebooted. A new keyring file has been generated and everything looks good for now!

This is affecting basic NetworkManager use cases. It's impossible to connect to any password protected wifi. I'd bet this bug is the cause of many other requiring access to the keyring storage.

For reference... https://github.com/karma-runner/karma-chrome-launcher/issues/76

again, confirming: `sudo apt-get remove --purge dbus-user-session` and reboot resolved it for me on Ubuntu 16.04. No side-effects. On reboot, the Passwords>Login keyring was available, where before it wasn't.

I can confirm as well that removing dbus-user-session and reboot worked like a charm. Thx all.

I can't believe all it took was to do:

sudo apt purge dbus-user-session

Thanks to whoever discovered this!

Sidenote: My Yandex browser now launches instantaneously rather than taking atleast half a minute to open up.

This fix was definitely a good find

This is not fixed. What we have is a reliable workaround to a bug which apparently affects all Ubuntu 16.04 LTS users with the dbus-user-session package installed.

Flatpak packages provided by the PPA at https://launchpad.net/~alexlarsson/+archive/ubuntu/flatpak (and possibly others) indirectly depend on this package and cause it to be installed (but this issue which seems to be a bug in Ubuntu 16.04 is not this PPA's fault).

$ apt-rdepends --reverse dbus-user-session
Reading package lists... Done
Building dependency tree
Reading state information... Done
dbus-user-session
  Reverse Depends: xdg-desktop-portal (0.8-0alexlarsson2~xenial)
  Reverse Depends: xdg-desktop-portal-gtk (0.7-0alexlarsson2~xenial)
xdg-desktop-portal
  Reverse Depends: xdg-desktop-portal-gtk (0.7-0alexlarsson2~xenial)
xdg-desktop-portal-gtk

Since there are multiple packages that depend on dbus-user-session, there's really no need to mention a single package in the title.

Status changed to 'Confirmed' because the bug affects multiple users.

I can replicate this problem on 16.04.3 after upgrade from 16.04.2. However, the package dragging in dbus-user-session are different in my case:

$ apt-rdepends --reverse dbus-user-session
Reading package lists... Done
Building dependency tree
Reading state information... Done
dbus-user-session
  Reverse Depends: razer-daemon (1.1.15-0ubuntu1)
razer-daemon
  Reverse Depends: polychromatic (>= 0.3.10-xenial)
polychromatic

Unfortunately I cannot remove dbus-user-session...

I did stop the long pause on chrome using a workaround found https://askubuntu.com/questions/911877/chrome-and-chromium-are-taking-a-long-time-to-load/911896
by setting up ~/.config/autostart/gnome-keyring-daemon.desktop

This still leaves me being prompted to unlock the keyring, which was not happening in 16.04.2

It turns out the workaround does resolve the long pause, but does not result in correct operation. Chrome has chrome sync not functioning, and gnome-encfs mounts fail unless manually mounted using gnome-encfs-manager

Uninstalling polychromatic, razer-daemon, and then dbus-user-session resolved the chrome problem.

I also have this issue in Ubuntu 17.10 (running gdm/gnome-shell). Uninstalling dbus-user-session isn't really an option, because tons of apps depend on it.

Rocko, please file a different bug for that issue.

Eric, please contact the distributor/maintainer for razer-daemon and polychromatic since those packages are not provided by Ubuntu.

I'm closing this bug since the issue was specific to the Flatpak PPA and that was resolved there weeks ago.

This bug was not only related to Flatpak. I have never installed/used/heard of Flapak before I filed this bug. Maybe this bug should be filed against dbus-user-session.

Status changed to 'Confirmed' because the bug affects multiple users.

Mike, what is the output of this command:

apt rdepends dbus-user-session

$ apt rdepends dbus-user-session
dbus-user-session
Reverse Depends:
 |Suggests: dbus
  Depends: anbox-common
 |Suggests: dbus
 |Suggests: dbus

Which I understand is not an official package and in my case, is no longer installed. The point is, dbus-user-session is an official package and causes major problems with Ubuntu if it is installed for any reason. I feel these problems should be fixed in the dbus-user-session package or in the packages it affects (gnome-keyring) when installed.

Jeremy,

razer-daemon committer identifies they are expressing a package dependency correctly, and if installing dbus-user-session causes chrome to break, that's not a driver/package problem. They have a point. https://github.com/terrycain/razer-drivers/issues/358

I would like to say that I am happy to gather data on this and debug it, if someone would help me understand where to look. If this was a kernel issue I would be beavering away, but this is gnome, and as far as I can tell dbus-user-session is systemd transition related, so I am less clueful.

Let me run an experiment. I will install dbus-user-session by itself. If this causes gnome-keyring not to unlock and thus chrome to fail, would we have consensus there is a problem here that has nothing to do with other packages that drag in dbus-user-session?

1. apt-get install dbus-user-session
2. reboot
3. confirm flatpak not installed:
emc@emc-office:~$ which flatpak

4. Check reverse dependancies and ensure there is nothing dependant on it

emc@emc-office:~$ apt-rdepends --reverse dbus-user-session
Reading package lists... Done
Building dependency tree
Reading state information... Done
dbus-user-session
  Reverse Depends: razer-daemon (1.1.15-0ubuntu1)
razer-daemon
  Reverse Depends: polychromatic (>= 0.3.10-xenial)
polychromatic
emc@emc-office:~$ sudo apt-get remove --purge razer-daemon polychromatic
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'polychromatic' is not installed, so not removed
Package 'razer-daemon' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

5. Check Passwords and Keys

Login section is missing

6. start chrome

emc@emc-office:~$ /opt/google/chrome/chrome
[4151:4181:0823/233754.144116:ERROR:nss_util.cc(802)] After loading Root Certs, loaded==false: NSS error code: -8018
Gkr-Message: secret service operation failed: 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.
[4151:4151:0823/233844.494199:ERROR:background_mode_manager_aura.cc(13)] Not implemented reached in virtual void BackgroundModeManager::EnableLaunchOnStartup(bool)
Gkr-Message: secret service operation failed: 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.
[4151:4176:0823/233909.532194:ERROR:token_service_table.cc(130)] Failed to decrypt token for service AccountId-103397427961759974994

7. Remove dbus-user-session, reboot and confirm problem resolved

Yep.

So I think this is clear that adding/deleting dbus-user-session induces seahorse to not unlock, cause undetermined, which then sets off failures for anyone using keys.

Chrome/Chromium should probably not wait that long if keyring is not available. If it is not running, then it is not running, end of story. Chromium should just proceed launching instead of bothering user with behavior like this.

After trying multiple options in this thread. I found that reinstalling the ca-certificates fixed this for me.

sudo apt-get install --reinstall ca-certificates

Reinstalling the ca-certificates did not work for me.

Only removing dbus-user-session works around the problem for me.

Also, openrazer & polychromatic no longer have the dependency on dbus-user-session. Thanks to the maintainers of these packages.

Any update on this issue? I do not feel comfortable removing dbus-user-session as a workaround, and I have simply added --password-store=basic as an argument for Chromium/Chrome for now. However that is not completely suitable even though I only use Chromium/Chrome as a secondary browser, and I am wondering if this issue is still being looked into, and am inquiring for perhaps more details about it if anyone has any more details like if the maintainers/developers of dbus-user-session (whoever they may be?) are aware of this bug, etc. I am using Ubuntu 16.04 and Xfce 4.12 and the latest google-chrome-stable, chromium-browser, dbus-user-session, etc. I see someone has stated back in August that using Ubuntu 17.10 with Gnome shell and gdm still produces this issue, I wonder if this is still the case or if this issue has been fixed by now at least on Ubuntu 17.10?

Also, on a side-note, does anyone know the exact details of what the password-store argument does? For example, if I turn password saving in Chromium off and don't use Google/Chrome sync, am I "safe" to log into websites without my passwords being stored in plain-text on my hard drive (even if temporary)?

I may end up looking into Kwallet to see if this is a suitable alternative to GNOME keyring at least for Chromium.

Thanks.

This bug is not resolved. Seeing it under 16.04LTS without dbus-user-session or flatpak installed.

smm@laptop /var/log
$ sudo apt list --installed |grep dbus-user-session

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

smm@laptop /var/log
$ sudo apt list --installed |grep flatpak

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

> Also, on a side-note, does anyone know the exact details of what the
> password-store argument does? For example, if I turn password saving
> in Chromium off and don't use Google/Chrome sync, am I "safe" to log
> into websites without my passwords being stored in plain-text on my
> hard drive (even if temporary)?

Yes you should be safe, chromium won't store passwords if the corresponding setting is off.

> I do not feel comfortable removing dbus-user-session as a workaround

Nothing in Ubuntu 16.04 LTS uses dbus-user-session. It is completely safe to remove it there.

> This bug is not resolved. Seeing it under 16.04LTS without
> dbus-user-session or flatpak installed.

I can reliably reproduce the issue of the keyring not being automatically unlocked at startup in an up-to-date 16.04 VM without dbus-user-session installed. Not seeing any application slowdown though, chromium doesn't block at startup, but it does pop up a dialog prompting to unlock the keyring.

That VM was configured to automatically log in the only user account though, and I had removed the user's password. After setting back a password for the user and disabling the automatic login, I verified that the keyring was correctly unlocked after logging in.

To everyone affected:
 - can you comment on whether you're seeing application slowdown/blocking when the login keyring is not unlocked?
 - can you share whether automatic login is enabled, and whether you have unset your user's password (this is not recommended)

 - I'm seeing slow downs.
 - I'm not using automatic login.

Thanks for the feedback Stephen. This thread has become very long and it's hard to extract the relevant information, so just to make sure that I fully understand the issue:

 - can you confirm that chrom{e,ium} takes a long time to open (in the original description it was 2 minutes, is this the same for you)?

 - if so, do you eventually see a popup prompting for your password to unlock the keyring?

 - after closing it and opening again, I take it it's not blocked on the keyring, assuming you previously unlocked it?

 - can you launch chromium from a terminal with the following command, and share the output:

      chromium-browser --enable-logging=stderr

Thanks in advance!

Olivier:
1) Yes
2) Yes
3) Yes
4) I'll have to log out and/or reboot to get it back into that state. Will post when I get a chance to do that.

Running "chromium-browser --enable-logging=stderr" results in:

$ chromium-browser --enable-logging=stderr
ATTENTION: default value of option force_s3tc_enable overridden by environment.

I'm also running the gnome-keyring-daemon in the foreground and see this message:

** (gnome-keyring-daemon:31165): WARNING **: asked to register item /org/freedesktop/secrets/collection/login/12, but it's already registered

** Message: The Secret Service was already initialized

Chromium starts up quickly, but network manager can't access the keyring and hangs for a minute or two before it gives up when I try to connect to a VPN. Then it prompts me for the passwords, as it was unable to retrieve them from gnome-keyring.

Killing and restarting the daemon fixes the problem. Every night I suspend my laptop when I go home and find the deamon is hung again the next morning.

After killing and restarting the keyring which fixed Network Manager, then Chromium developed a slow start problem caused by gnome-keyring.

smm@laptop ~
$ chromium-browser --enable-logging=stderr
ATTENTION: default value of option force_s3tc_enable overridden by environment.
Gkr-Message: secret service operation failed: 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.
[7981:7981:0314/102437.107901:WARNING:password_store_factory.cc(241)] Using basic (unencrypted) store for password storage. See https://chromium.googlesource.com/chromium/src/+/master/docs/linux_password_storage.md for more information about password storage options.

Every time I turn around, I have a no failure related to gnome-keyring. After having Chromium running for a few minutes it hangs again for a minute or so with the same error message:

Gkr-Message: secret service operation failed: 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.

Keyring may end up making Chromium unusable.

I still experience this bug in 18.04.

Billy, please file a new bug for your issue with specific details about what you're experiencing.

Ran into this after installing dbus-user-session in order to support systemd user services that raise notifiers via dbus.

Notifiers didn't arrive via my desktop so I presume it just creates a whole other session somewhere and talks to that. My service worked (when it was previously crashing because of lack of a dbus to talk to), but it started an extra gnome-keyring-daemon (the dialog for that DID appear in my desktop session), and then I had the slow-alt-T problem.

Ah well, I shall go back to running my bugwarrior sync manually until I can find documentation of systemd user services that actually works...

Could this be an incompatibility between i386 and amd64 packages? I have trouble adding my keys via ssh-add and after reading some comments here and elsewhere gave removing dbus-user-session a try. My computer is amd64 with i386 foreign arch. dbus-user-session was replaced with dbus-user-session:i386 and a few other :386 packages. After the installation, the situation was much worse, with ssh-add completely hanging now.

Hi guys,
This bug is still present on latest versions (seahorse 3.30).
Why is assigned to chromium-browser package?

As with comment #107, `sudo apt-get install --reinstall ca-certificates` was the only fix for me. Removing/re-installing/re-configuring dbus-user-session didn't help. This points to there being two issues. Neither issue is related to chrome.

This also happens in disco dingo (19.04). Only solution is running `gnome-keyring-daemon` on a terminal.

Uninstalling `dbus-user-session` or doing `sudo apt-get install --reinstall ca-certificates` doesn't do anything.