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

Bug #1689825 reported by Mike Rushton on 2017-05-10
398
This bug affects 76 people
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
Undecided
Unassigned
dbus (Ubuntu)
Undecided
Unassigned
flatpak (Ubuntu)
Undecided
Unassigned

Bug Description

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) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-keyring (Ubuntu):
status: New → Confirmed
Tony Maro (tonymaro) wrote :

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

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

Mike Rushton (leftyfb) on 2017-05-11
summary: - ubuntu 16.04 Chrome and Chromium asking for keyring.
+ gnome-keyring not unlocked on boot

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.

Marc Pignat (swid) wrote :

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

Mike Rushton (leftyfb) wrote :

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.

Hassan Williamson (hazrpg) wrote :

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

Hassan Williamson (hazrpg) wrote :

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

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

Changed in libgnome-keyring (Ubuntu):
status: New → Confirmed
Hassan Williamson (hazrpg) wrote :

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

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.

meeck (meeck) wrote :

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

redman (patrick-libert) wrote :

Same problem here:

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

Nikolas Hedberg (drhedberg) wrote :

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

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.

Hans Deragon (deragon) wrote :

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

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

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

Changed in chromium-browser (Ubuntu):
status: New → Confirmed
513G3 (513g3) wrote :

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.

Mike Rushton (leftyfb) wrote :

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

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

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.

Changed in chromium-browser (Ubuntu):
status: Confirmed → Invalid
MikeD (mike-dymott) wrote :

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.

513G3 (513g3) wrote :

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

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

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

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

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.

Changed in gdm (Ubuntu):
status: New → Confirmed
Changed in lightdm (Ubuntu):
status: New → Confirmed
Mike Rushton (leftyfb) on 2017-07-08
Changed in flatpak (Ubuntu):
status: New → Invalid
513G3 (513g3) on 2017-07-14
Changed in flatpak (Ubuntu):
status: Invalid → Confirmed
26 comments hidden view all 106 comments
513G3 (513g3) wrote :

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

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.

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

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

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

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

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

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

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

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.

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 (gerald-maruccia-e) wrote :

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

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

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

Thanks to all contributors.

jose (jose-cybergalvez) wrote :

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

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

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

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.

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

followed by a reboot fixed it!

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

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

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

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

Eugene Jones (eugenerjones) wrote :

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

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

summary: - gnome-keyring not unlocked on boot
+ gnome-keyring not unlocked on xenial when dbus-user-session is
+ installed, which flatpak depends on
Mike Rushton (leftyfb) wrote :

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

summary: - gnome-keyring not unlocked on xenial when dbus-user-session is
- installed, which flatpak depends on
+ gnome-keyring not unlocked on xenial when dbus-user-session is installed
Launchpad Janitor (janitor) wrote :

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

Changed in dbus (Ubuntu):
status: New → Confirmed
Eric Carroll (eric-carroll) wrote :

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

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

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

Rocko (rockorequin) wrote :

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 Bicha (jbicha) wrote :

Rocko, please file a different bug for that issue.

Jeremy Bicha (jbicha) wrote :

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.

Changed in flatpak (Ubuntu):
status: Confirmed → Fix Released
no longer affects: gdm (Ubuntu)
no longer affects: lightdm (Ubuntu)
no longer affects: libgnome-keyring (Ubuntu)
no longer affects: gnome-keyring (Ubuntu)
Changed in dbus (Ubuntu):
status: Confirmed → Triaged
Mike Rushton (leftyfb) wrote :

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

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

Changed in meta-gnome3 (Ubuntu):
status: New → Confirmed
Jeremy Bicha (jbicha) wrote :

Mike, what is the output of this command:

apt rdepends dbus-user-session

affects: dbus → meta-gnome3 (Ubuntu)
no longer affects: meta-gnome3 (Ubuntu)
Mike Rushton (leftyfb) wrote :

$ 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) wrote :

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

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

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.

Displaying first 40 and last 40 comments. View all 106 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.