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

Bug #1689825 reported by Mike Rushton on 2017-05-10
370
This bug affects 70 people
Affects Status Importance Assigned to Milestone
D-Bus
New
Undecided
Unassigned
chromium-browser (Ubuntu)
Undecided
Unassigned
dbus (Ubuntu)
Undecided
Unassigned
flatpak (Ubuntu)
Undecided
Unassigned
gdm (Ubuntu)
Undecided
Unassigned
gnome-keyring (Ubuntu)
Undecided
Unassigned
libgnome-keyring (Ubuntu)
Undecided
Unassigned
lightdm (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.

Photon (michael-kogan) wrote :

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?

Photon (michael-kogan) wrote :

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

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

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

Changed in gdm (Ubuntu):
status: New → Confirmed
Changed in lightdm (Ubuntu):
status: New → Confirmed
Coeur Noir (gerald-maruccia-e) wrote :

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

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

Photon (michael-kogan) wrote :

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

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

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

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

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.

Changed in flatpak (Ubuntu):
status: New → Invalid
513G3 (513g3) wrote :

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

513G3 (513g3) wrote :

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

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.

Photon (michael-kogan) wrote :

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

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.

Photon (michael-kogan) wrote :

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

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

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

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

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

Finally, this fixed the problem.

redman (patrick-libert) wrote :

Thanks for everyone who helped

513G3 (513g3) wrote :

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

Changed in flatpak (Ubuntu):
status: Invalid → Confirmed
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.

To post a comment you must log in.
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.