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

[Mike Rushton]

1) Release: 16.04.2
2) gnome-keyring: 3.18.3-0ubuntu2
3) Login. gnome-keyring unlocks "login" features including for google chrome
4) gnome-keyring is not unlocked, chrome takes 2 minutes to open and with no secure password features(sync) functioning.

For the past couple days, chrome on Ubuntu 16.04 takes a REALLY long time (maybe 2 minutes) to start. Once chrome is started, I am not able to sync and any secure password features are broken. I found out this is due to gnome-keyring not being unlocked at login. There's also no way to unlock the "login" portion of the keyring from the running daemon by default. I have to kill the gnome-keyring process and start without "--login" as a parameter. Then the "login" section shows up which I'm able to unlock. From there chrome starts up instantly but asks the following:

Enter password to unlock your login keyring
The login keyring did not get unlocked when you logged into your computer

After that, all of it's sync and secure features are functional.

Starting google-chrome-stable from a command line at boot without running the above workaround shows the following error messages:

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.
[4364:4393:0510/100407.740292:ERROR:token_service_table.cc(130)] Failed to decrypt token for service AccountId-108842767310111573264
[4364:4445:0510/100407.740292:ERROR:gcm_store_impl.cc(929)] Failed to restore security token.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: gnome-keyring 3.18.3-0ubuntu2
ProcVersionSignature: Ubuntu 4.8.0-52.55~16.04.1-generic 4.8.17
Uname: Linux 4.8.0-52-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: amd64
CurrentDesktop: GNOME-Flashback:Unity
Date: Wed May 10 09:43:37 2017
SourcePackage: gnome-keyring
UpgradeStatus: No upgrade log present (probably fresh install)

[Mike Rushton (leftyfb)]

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

[Launchpad Janitor (janitor)]

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

[Tony Maro (tonymaro)]

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.

[Ken (kgaulter)]

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

[Antonios Hadjigeorgalis (antonioshadji)]

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".

[Antonios Hadjigeorgalis (antonioshadji)]

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

[Jan Philipp Wächter (jan-waechter)]

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.

[Marc Pignat (swid)]

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

[Mohammad Anwar Shah (mohammadanwarshah)]

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

[Mike Rushton (leftyfb)]

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.

[Mohammad Anwar Shah (mohammadanwarshah)]

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

[Hassan Williamson (hazrpg)]

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

[Hassan Williamson (hazrpg)]

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.

[Launchpad Janitor (janitor)]

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

[Hassan Williamson (hazrpg)]

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?

[Derek Chafin (infomaniac50)]

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.

[TenLeftFingers (tenleftfingers)]

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

[meeck (meeck)]

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.

[ThomasRosenkranz (tom-rosary-q)]

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

[redman (patrick-libert)]

Same problem here:

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

[Nikolas Hedberg (drhedberg)]

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.

[Pablo Sanabria (tailmon)]

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

[Dario Menin (darioalessio-menin)]

This also affects chromium-browser installed from Ubuntu repository.

[Hans Deragon (deragon)]

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.

[Keith Newman (0eith)]

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.

[Launchpad Janitor (janitor)]

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

[513G3 (513g3)]

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...

[Dario Menin (darioalessio-menin)]

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.

[Mike Rushton (leftyfb)]

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.

[Radim Vavřík (rvavrik)]

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

[Olivier Tilloy (osomon)]

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.

[MikeD (mike-dymott)]

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.

[Dario Menin (darioalessio-menin)]

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.

[513G3 (513g3)]

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

[513G3 (513g3)]

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.

[MikeD (mike-dymott)]

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".

[MikeD (mike-dymott)]

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!

[Javier Fernandez (lajava)]

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.

[513G3 (513g3)]

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

[Michael Kogan (michael-kogan)]

I experience the same problem on Manjaro Linux with gnome-keyring 3.20.0+57+g9db67ef6 and skypeforlinux. So it seems to be a bug in gnome-keyring, not in Ubuntu's package.

Some observations (citing my post on the Manjaro forums https://forum.manjaro.org/t/skypeforlinux-weird-and-inconsistent-authentification-behaviour/26076):

I read that the old Skype client will stop working on Juli 1st, that is in less than two weeks, so I switched to the new client on several machines. However, the new client behaves in a weird way on starting up:

 1. On some machines the user gets logged in without being asked for his password
 2. On some machines the user gets a gnome-keyring password dialogue
 3. On some machines the user has to enter the complete Skype user name and password into the Skype client itself

In the ideal world I would like to have all machines behave as in 1. But how to do so? Does anybody else experience the same problem?

I have digged deeper into this issue. It turned out that the gnome-keyring-daemon is running with different command lines in the three cases.

Case 1:
gnome-keyring-daemon --start --foreground --components=secrets (on my Manjaro laptop)
gnome-keyring-daemon --start (on my old Arch install)

Case2:
gnome-keyring-daemon is not running at all. It is then launched when skypeforlinux is started and needs a password to unlock the keyring.

Case3:
gnome-keyring-daemon --daemonize --login

So there seem to be two problems: First, the problem that gnome-keyring-daemon is not launched at login at all, second, if it is launched, it is launched with a bad command line.

I looked in the Xfce session settings and there is an entry for gnome-keyring-daemon with the correct (Case 1) command line, but it is not activated. I activated it, but it seems to have changed nothing, gnome-keyring is still launched with the wrong command line. It looks like it is started by some system wide service and then the Xfce session settings entry collides with the already running instance. But what is this system wide service and why does it use the wrong command line on some machines but the right command line on others?

[Michael Kogan (michael-kogan)]

I need to correct my previous statement. It looks like skypeforlinux is actually starting the

  gnome-keyring-daemon --start --foreground --components=secrets

command line, it is not there at boot. The

  gnome-keyring-daemon --daemonize --login

command line seems to sometimes be there and sometimes not, on all machines.

[513G3 (513g3)]

The problem really is isolated to gnome-keyring (as OP and others stated).

Here's my workaround for Chrome... it might help others (like Photon). But in the end it is only a workaround. It does demonstrate that if you bypass the display manager (lightdm, gdm) triggering the gnome-keyring for you, everything works great.

By having a session not orchestrated by a display manager, apps work correctly:

$ ssh -X localhost
$ google-chrome &

[Launchpad Janitor (janitor)]

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

[Coeur Noir (coeur-noir)]

Affected here on Ubuntu 16.04 Unity.

I noticed it on trying to launch chromium-browser, it takes very long with errors

coeurnoir@Asgard:~$ chromium-browser
Using PPAPI flash.
 --ppapi-flash-path=/usr/lib/adobe-flashplugin/libpepflashplayer.so --ppapi-flash-version=
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.
[14639:14687:0702/211518.780149:ERROR:crx_installer.cc(735)] Impossible de charger l'icône de l'extension "icons/192.png". edcifkpoamnkimdpjiabhfjahoinbpbps

Only one user-session out of 3 on the same machine seems affected for the moment.

On the affected session I installed yesterday flatpak from ppa:alexlarsson/flatpak in order to try latest version of pitivi. Installing pitivi through flatpak asked to connect to gnome3.22 related stuff … any hint there ? Because chromium get slow right after that installation.

I did uninstall pitivi through flatpak command, then ppa-purged flatpak but things did not get better.

Screen-capture by keyboard-shortcut is also very slow ( it finally happens when chromium stops hanging ).

Same story in french there → https://forum.ubuntu-fr.org/viewtopic.php?id=2011625

[Coeur Noir (coeur-noir)]

Well… now the problem happens on all the users-sessions but the error message is little different :

alessandra@Asgard:~$ chromium-browser
Using PPAPI flash.
 --ppapi-flash-path=/usr/lib/adobe-flashplugin/libpepflashplayer.so --ppapi-flash-version=
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.
[5958:5995:0702/224636.598323:ERROR:token_service_table.cc(130)] Failed to decrypt token for service AccountId-118233930601834352306

[Michael Kogan (michael-kogan)]

A followup on my report about skypeonlinux: It looks like the problem is related to some user config in this case. If I create a clean user, gnome-keyring works as expected. However, I wasn't able to find where exactly the problematic configuration file is located yet.

[Coeur Noir (coeur-noir)]

This bug also prevents Deja-dup / duplicity from working.

Launching manually from terminal

gnome-keyring-daemon

seems to help a little.

When launching chromium password is asked but after that chromium and any other app's seem to work fine.

[Coeur Noir (coeur-noir)]

…for a couple of hours then chromium says ( something like ) Error occurs when trying to open your profile.

[Coeur Noir (coeur-noir)]

Is this any useful https://bugzilla.gnome.org/show_bug.cgi?id=784514 ?

[Sébastien Tisserant (s-tisserant)]

For what it's worth, as other users already mentioned that, the issue appeared after I installed flatpack and pitivi (yesterday). I uninstalled both of them and cleaned remaining files but the problem still occurs...

Flatpak might be related to the issue, or at least one of the triggers.

[Mike Rushton (leftyfb)]

It does not have anything to do with flatpack or pitivi. I have several machines experiencing this issue and have never installed either of the mentioned packages on any of them in any point in time.

[513G3 (513g3)]

@MikeRushton... do you have any PPAs installed on your machines without flatpak?

[513G3 (513g3)]

FWIW, my problem started after installing PPAs about a week before I first posted here (June 17). I just checked my /etc/apt/sources.list and it was last modified June 10. Perhaps it is coincidence... but right when some PPAs went in, my problem started.

[Chris (syphist)]

It may not be flatpak on its own, but the machine I installed (and later removed and purged) flatkpak on this problem exists. (So a correlation does seem to exist) It might have something to do with other PPAs or how packages you install from external PPAs affect the system. The only major changes I made with the system around the time this happened was installing flatpak (and monodevelop through it), wine updating to 2.11 staging, and some retroarch cores updating. Also it might be worth looking into how exactly the gnome-keyring-daemon is started on login to see if there is a manual edit to some file that could resolve this issue. Sadly I don't have much else to offer other than that I am using Xubuntu 16.04.2 and have decided that the best temporary fix is to just enter my password in a second time by automatically starting the keyring daemon on startup.

[Michael Kogan (michael-kogan)]

@all: Please try if the problem appears for a new clean user. In my case it didn't so I suspect that it is related to some configuration files in ~/.

[Radim Vavřík (rvavrik)]

In my case, the problem appears also for the new clean user. I tried a new standard user without password, a new standard user with password and a new administrator user with password, but it did the same in all cases.

[Michael Kogan (michael-kogan)]

Thanks for testing, looks like several different bugs are mixed up here (or it's just me posting a similar problem in the wrong bug report...).

[Coeur Noir (coeur-noir)]

…flatpak may not be the source problem but it seems to bring something that helps highlighting the problem… ( I suspect some gnome-related parameters ).

I assume some other ppa's as well can bring the same problem, maybe by comparing them we could narrow down a culprit ?

I can also confirm that once the problem surfaces it affects all the users on the machine ( ubuntu 16.04 unity here ).

[Coeur Noir (coeur-noir)]

To illustrate an other side-effect :

coeurnoir@Asgard:~$ deja-dup --backup

** (deja-dup:2774): WARNING **: AssistantOperation.vala:732: Erreur lors de l'appel de StartServiceByName pour org.freedesktop.secrets : GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.freedesktop.secrets': timed out

[Eberhard Beilharz (ermshiperete)]

I could work around this problem by uninstalling dbus-user-session (and its dependendants xdg-desktop-portal and xdg-desktop-portal-gtk). Those packages came in through flatpak.

Thanks to Olaf who brought me on the right track (https://forum.ubuntuusers.de/topic/gnome-keyring-daemon-doppelt/)

[markuslet (markuslet)]

That finally solved it for me, thank you @Eberhard and @all for looking into this and sharing your insights!

A few notes:

* in addition, I manually deleted file /etc/X11/Xsession.d/20dbus_xdg-runtime which comes with package dbus-user-session (and is actually the only file of the package) but was not removed on uninstall (Idk whether this step is always neccessary)

* logout/login was not sufficient to see this solved. Full reboot was required.

[redman (patrick-libert)]

Finally, this fixed the problem.

[redman (patrick-libert)]

Thanks for everyone who helped

[513G3 (513g3)]

The Status dropdown is for "Affects" and flatpak affects this issue (not that it's the sole culprit).

[513G3 (513g3)]

Thanks all!

I uninstalled my flatpak apps, flatpak, and dbus-user-session... then rebooted and all's well. Uninstalling with --purge seems to have taken care of the /etc file markuslet pointed to.

$ flatpak list
$ flatpak --system uninstall com.xamarin.MonoDevelop
$ flatpak --system uninstall org.freedessktop.Platform
$ sudo apt-get remove --purge dbus-user-session
$ sudo apt-get remove --purge flatpak
$ sudo apt-get autoremove
$ sudo reboot

[Mike Rushton (leftyfb)]

Removing dbus-user-session resolved my issue. It got added when I temporarily installed anbox. There was no xdg-desktop-portal or xdg-desktop-portal-gtk installed or available.

[Antonios Hadjigeorgalis (antonioshadji)]

Removing flatpak/dbus-user-session did not change anything for me on 16.04.2. dbus-user-session was first installed on May 8th 2017 in conjunction with an upgrade of flatpak (and other software) as can be seen in attached apt history log entry.

flatpak list
org.pitivi.Pitivi/x86_64/stable
org.gnome.Platform/x86_64/3.22 user,runtime

flatpak --user uninstall org.pitivi.Pitivi
flatpak --user uninstall org.gnome.Platform

apt-get purge flatpak
autoremoved
 libostree-1-1 xdg-desktop-portal xdg-desktop-portal-gtk

apt-get purge dbus-user-session

reboot and check for running gnome-keyring-daemon

$ psa | grep gnome-keyring-daemon
antonios 4592 0.0 0.0 14524 980 pts/17 S+ 13:58 0:00 | \_ grep gnome-keyring-daemon
lightdm 1589 0.0 0.0 123296 3148 ? Sl 13:56 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
antonios 2652 0.1 0.2 232048 34776 ? SLl 13:57 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login

the lightdm owned process stopped running after a few minutes.

to workaround, I still have to run
`gnome-keyring-daemon --replace'

[Mike Rushton (leftyfb)]

@antonioshadji

I had to undo the workarounds in order for it to stop asking for passwords at login:

In /etc/xdg/autostart/gnome-keyring-ssh.desktop

I originally replaced:

Exec=/usr/bin/gnome-keyring-daemon --start --components=ssh

with

#Exec=/usr/bin/gnome-keyring-daemon --daemonize --components=ssh

Some people put a new gnome-keyring startup file in ~/.config/autostart/
Remove that.

Then a complete reboot.

[Antonios Hadjigeorgalis (antonioshadji)]

Thank you, @leftyfb.

I'm seeing some strange behavior when deleting the files in ~/.config/autostart/

I can delete the file. If I open the GUI for startup Applications it has a line for gnome-keyring-daemon --start --components=ssh which seems unrelated to the text file in ~/.config/autostart. If I delete both the GUI entry and the text file and reboot, I get the same behaviour and have to run gnome-keyring-daemon --replace and enter my password. I also have to open the HUD to get the password prompt to show itself otherwise nothing happens.

Also after reboot, the entry in the startup applications gui shows up again even though the text file is not there. Upon closing the GUI, the text file appears again.

As for the rest of the system,

In /etc/xdg/autostart I have three gnome-keyring-daemon files for secrets, ssh, and pkcs11. These files have been here since November 2015.

They contain:

Exec=/usr/bin/gnome-keyring-daemon --start --components={{one of secrets, ssh, or pkcs11}}

the rest of these three files are the same and contain the following lines:

OnlyShowIn=GNOME;Unity;MATE;
X-GNOME-Autostart-Phase=Initialization
X-GNOME-AutoRestart=false
X-GNOME-Autostart-Notify=true
X-GNOME-Bugzilla-Bugzilla=GNOME
X-GNOME-Bugzilla-Product=gnome-keyring
X-GNOME-Bugzilla-Component=general
X-GNOME-Bugzilla-Version=3.18.3
NoDisplay=true

[Antonios Hadjigeorgalis (antonioshadji)]

I added a bad command line into the GUI and .config/autostart file to be sure that it could not run the command to start the daemon.

upon reboot I still see two daemons running, one with my username as owner and one with lightdm as owner.
I'm still getting the same behavior of slow launch of terminal and extremely long load of chrome if I don't run the workaround command gnome-keyring-daemon --replace and enter my password.

After logging in for the second time, the daemon owned by lightdm exits leaving only one daemon running owned by my user.

[Mike Rushton (leftyfb)]

All I have running is /usr/bin/gnome-keyring-daemon --daemonize --login

The files in your /etc/xdg/autostart look fine

Just need to make sure you're not starting gnome-keyring anywhere else.

[Byte Commander (bytecommander)]

Seems to me like `dbus-user-session` was the real culprit causing all the trouble.
I got it installed with anbox and that is when the problem started.

I got my keyring daemon to correctly start, the Login keyring to unlock automatically while still being encrypted with my account password again this way:

- Purge `dbus-user-session`, e.g. by running `sudo apt purge dbus-user-session`
- Revert files in `/etc/pam.d` back to their original state. I had commented out a line in `/etc/pam.d/lightdm` to work around the `gnome-keyring-daemon` not starting in the correct mode issue.
- Set my account password on the Login keyring again (using seahorse). I had removed the password and left the keyring unprotected to avoid being asked for the password each session.
- Set my user account password to something completely different and then back to my normal password using the `passwd` command. Before doing this, it seemed like the Login keyring and account password weren't yet synced correctly despite being equal. When I rebooted before the `passwd`, it still asked for the keyring password to be entered manually.
- Reboot. On my next login, it asked for the Login keyring password to be entered manually one last time, but offered a checkbox to enable unlocking that keyring automatically on boot, which I checked.

After this procedure, my system seems to be as good as new again. Running 16.04 with vanilla Unity desktop and lightdm btw.

[Radim Vavřík (rvavrik)]

I can confirm that removing the dbus-user-session and reverting a workaround (calling the gnome-keyring-daemon --replace --foreground) solved the issue. There was no xdg-desktop-portal or xdg-desktop-portal-gtk packages in my case. I suppose the dbus-user-session was installed with the flatpak. Ubuntu 16.04.2 LTS

[Eric Alzheimer (ealzheimer)]

I can also confirm that removing dbus-user-session fixes this issues, and it was installed with flatpak. The steps in #67 got everything back to normal. Thanks to Eberhard and 513G3 for the solution.

[Antonios Hadjigeorgalis (antonioshadji)]

I can now confirm that these instructions have worked for me. Thank you all. I did change my password as suggested in comment #74 by bytecommander.

[Coeur Noir (coeur-noir)]

I can also confirm that un-installing dbus-user-session solved the issue.

Does flatpak always install it / or only some app's ?

[Sébastien Tisserant (s-tisserant)]

Same here. Uninstalling dbus-user-session solved the issue.

Thanks to all contributors.

[jose (jose-cybergalvez)]

I've not tried it yet, but I'm sure that uninstalling dbus-user-session works as a workaround. what concerns me is what consequences will this have. I checked 16.10 and 17.04 and both have dbus-user-session installed by default. When I install chrome I don't seem to get the same issues. I haven't installed flatpak to see if that recreates the problem on 17. So how does removing dbus-user-session solve this problem?

[Gunnar Hjalmarsson (gunnarhj)]

dbus-user-session is a dependency of the desktop meta packages, so uninstalling it means that you on Unity uninstall ubuntu-session and ubuntu-desktop, on GNOME Flashback you uninstall gnome-session-flashback etc.

[jose (jose-cybergalvez)]

Thank you, I really don't think that this is a good solution

On 07/18/2017 03:53 PM, Gunnar Hjalmarsson wrote:
> dbus-user-session is a dependency of the desktop meta packages, so
> uninstalling it means that you on Unity uninstall ubuntu-session and
> ubuntu-desktop, on GNOME Flashback you uninstall gnome-session-flashback
> etc.
>

[Byte Commander (bytecommander)]

It might have changed in the newer releases of Ubuntu, but on 16.04 (Unity desktop) `dbus-user-session` is NOT installed by default and NOT a dependency of any standard packages.

I myself got it as dependency of Anbox. Now that this is gone, the only remaining thing that points to this package is `dbus`, but as a suggestion. Suggestions are optional dependencies that do not automatically get installed unless you explicitly command `apt` to do so.

Also if you would remove something which another (meta-)package recommends or suggests (not hard dependencies), that wouldn't uninstall this other package. And even if so, in case of the desktop meta-packages like `ubuntu-desktop` it would not make a difference anyway, as these don't have a function other than initially installing all stuff. No harm in them being removed.

[Paolo Roth (p-m-roth86)]

An easy workaround, while waiting a fix, is to add a startup application with this command

/usr/bin/gnome-keyring-daemon *

You will be required to re-enter the password once logged, but it should work.

[David Spoelstra (davids-mediamachine)]

$ sudo apt-get remove --purge dbus-user-session

followed by a reboot fixed it!

[Matteo Capobianco (m-capobianco)]

I'm having this problem on a machine that doesn't have dbus-user-session installed, nor it ever had it installed.

The problem started to appear after installing Google Chrome (although it was quite fresh: I hadn't use it for anything else, apart from opening Firefox to download Chrome).

Note: it was a Ubuntu Server machine "converted" to Desktop by installing the ubuntu-desktop metapackage.

[yco (yco)]

I was having the same symptoms on my laptop (first, on debian stretch and then ubuntu 16.04 LTS).
I had neither installed flatpak nor dbus-user-session, and the gnome-keyring-daemon proposed workaround fixes didn't work for me.

I eventually found that it came from a CUPS configuration file (/etc/cups/client.conf), which was targeting an unreachable cups server.

I don't really get how a cups configuration would interfere with user functions, but it clearly did for me.

[Kevin Ard (ard-kevin-84)]

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.

[Piotr Trembecki (pinolec)]

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

[Chigozirim Chukwu (eugenerjones)]

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

[Tom Reynolds (tomreyn)]

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

[Mike Rushton (leftyfb)]

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

[Launchpad Janitor (janitor)]

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

[Eric Carroll (eric-carroll)]

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

[Eric Carroll (eric-carroll)]

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

[Eric Carroll (eric-carroll)]

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

[Rocko (rockorequin)]

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.

[Jeremy Bícha (jbicha)]

Rocko, please file a different bug for that issue.

[Jeremy Bícha (jbicha)]

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.

[Mike Rushton (leftyfb)]

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.

[Launchpad Janitor (janitor)]

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

[Jeremy Bícha (jbicha)]

Mike, what is the output of this command:

apt rdepends dbus-user-session

[Mike Rushton (leftyfb)]

$ 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.

[Eric Carroll (eric-carroll)]

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?

[Eric Carroll (eric-carroll)]

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.

[Iiro Laiho (iiro)]

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.

[Bransin Anderson (bransinanderson)]

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

[Eric Carroll (eric-carroll)]

Reinstalling the ca-certificates did not work for me.

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

[Eric Carroll (eric-carroll)]

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

[ipkpjersi (ipkpjersi)]

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.

[Stephen M (yourjunkhere14)]

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.

[Olivier Tilloy (osomon)]

> 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.

[Jeremy Bícha (jbicha)]

> 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.

[Olivier Tilloy (osomon)]

> 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)

[Stephen M (yourjunkhere14)]

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

[Olivier Tilloy (osomon)]

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!

[Stephen M (yourjunkhere14)]

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.

[Stephen M (yourjunkhere14)]

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.

[Stephen M (yourjunkhere14)]

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.

[Stephen M (yourjunkhere14)]

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.

[Billy Braga (billybraga)]

I still experience this bug in 18.04.

[Jeremy Bícha (jbicha)]

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

[Adrian Wilkins (adrian-wilkins)]

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...

[Rolf Leggewie (r0lf)]

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.

[Daniele Besana (WP-OK) (daniele-wpok)]

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

[James Tunnicliffe (dooferlad)]

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.

[Ramón Casero (rcasero)]

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.