gnome-keyring not unlocked on xenial when dbus-user-session is installed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
chromium-browser (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
dbus (Ubuntu) |
Triaged
|
Undecided
|
Unassigned | ||
flatpak (Ubuntu) |
Fix Released
|
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-
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:
[4364:4445:
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: gnome-keyring 3.18.3-0ubuntu2
ProcVersionSign
Uname: Linux 4.8.0-52-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: amd64
CurrentDesktop: GNOME-Flashback
Date: Wed May 10 09:43:37 2017
SourcePackage: gnome-keyring
UpgradeStatus: No upgrade log present (probably fresh install)
Mike Rushton (leftyfb) wrote : | #1 |
- Dependencies.txt Edit (7.3 KiB, text/plain; charset="utf-8")
- JournalErrors.txt Edit (53.8 KiB, text/plain; charset="utf-8")
- ProcEnviron.txt Edit (112 bytes, text/plain; charset="utf-8")
Launchpad Janitor (janitor) wrote : | #3 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in gnome-keyring (Ubuntu): | |
status: | New → Confirmed |
Tony Maro (tonymaro) wrote : | #4 |
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 : | #5 |
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:/
summary: |
- ubuntu 16.04 Chrome and Chromium asking for keyring. + gnome-keyring not unlocked on boot |
Antonios Hadjigeorgalis (antonioshadji) wrote : Re: gnome-keyring not unlocked on boot | #6 |
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-
[3823:3823:
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:
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:
Starting
[1:1:0513/
Antonios Hadjigeorgalis (antonioshadji) wrote : | #7 |
I'm also seeing slow response to taking a screenshot with shortcut keys.
Jan Philipp Wächter (jan-waechter) wrote : | #8 |
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-
Marc Pignat (swid) wrote : | #9 |
vinagre is also affected, running gnome-keyring-
Mohammad Anwar Shah (mohammadanwarshah) wrote : | #10 |
This askUbuntu answer actually fixed the issue cleanly https:/
gnome-
Mike Rushton (leftyfb) wrote : | #11 |
That is not a fix. It is a workaround. On boot, my system has gnome-keyring-
Mohammad Anwar Shah (mohammadanwarshah) wrote : | #12 |
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 : | #13 |
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 : | #14 |
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 : | #15 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in libgnome-keyring (Ubuntu): | |
status: | New → Confirmed |
Hassan Williamson (hazrpg) wrote : | #16 |
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 : | #17 |
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-
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:/
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) wrote : | #18 |
Opera is also affected by this issue. Takes almost a minute to load whereas Firefox loads in under five seconds.
meeck (meeck) wrote : | #19 |
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) wrote : | #20 |
same for me here
by starting with the terminal
$google-chrome
[6136:6136:
[6136:6136:
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:
at inject_code (chrome-
after
$sudo apt install gnome-themes-
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-
And the browser started immediately :-D
redman (patrick-libert) wrote : | #21 |
Same problem here:
Google-chrome is affected.
Skypeforlinux doesn't remember the password anymore
UnityMail is affected
Nikolas Hedberg (drhedberg) wrote : | #22 |
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 : | #23 |
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) wrote : | #24 |
This also affects chromium-browser installed from Ubuntu repository.
Hans Deragon (deragon) wrote : | #25 |
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 : | #26 |
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 : | #27 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in chromium-browser (Ubuntu): | |
status: | New → Confirmed |
513G3 (513g3) wrote : | #28 |
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) wrote : | #29 |
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 : | #30 |
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 : | #31 |
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 : | #32 |
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 : | #33 |
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-
The machine with the problem is almost useless for the moment - would be great to get a solution.
Dario Menin (darioalessio-menin) wrote : | #34 |
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:/
513G3 (513g3) wrote : | #35 |
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 : | #36 |
- log_in_and_out.txt Edit (781 bytes, text/plain)
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 : | #37 |
On my machine I'm unable to get any of the above workarounds to unlock the keyring. Entering...
gnome-keyring-
...ends in the terminal hanging at "SSH_AUTH_
MikeD (mike-dymott) wrote : | #38 |
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/
...and rebooted. A new keyring file has been generated and everything looks good for now!
Javier Fernandez (lajava) wrote : | #39 |
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) wrote : | #40 |
For reference... https:/
Michael Kogan (michael-kogan) wrote : | #41 |
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:/
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-
Case 1:
gnome-keyring-
gnome-keyring-
Case2:
gnome-keyring-
Case3:
gnome-keyring-
So there seem to be two problems: First, the problem that gnome-keyring-
I looked in the Xfce session settings and there is an entry for gnome-keyring-
Michael Kogan (michael-kogan) wrote : | #42 |
I need to correct my previous statement. It looks like skypeforlinux is actually starting the
gnome-
command line, it is not there at boot. The
gnome-
command line seems to sometimes be there and sometimes not, on all machines.
513G3 (513g3) wrote : | #43 |
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 : | #44 |
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 (coeur-noir) wrote : | #46 |
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-
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:
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
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:/
Coeur Noir (coeur-noir) wrote : | #47 |
Well… now the problem happens on all the users-sessions but the error message is little different :
alessandra@
Using PPAPI flash.
--ppapi-
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:
Michael Kogan (michael-kogan) wrote : | #48 |
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) wrote : | #49 |
- if of any help ps -fux Edit (10.0 KiB, text/plain)
This bug also prevents Deja-dup / duplicity from working.
Launching manually from terminal
gnome-keyring-
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) wrote : | #50 |
- chromium having problem to open profile Edit (167.2 KiB, image/png)
…for a couple of hours then chromium says ( something like ) Error occurs when trying to open your profile.
Coeur Noir (coeur-noir) wrote : | #51 |
Is this any useful https:/
Sébastien Tisserant (s-tisserant) wrote : | #52 |
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 : | #53 |
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 : | #54 |
@MikeRushton... do you have any PPAs installed on your machines without flatpak?
513G3 (513g3) wrote : | #55 |
FWIW, my problem started after installing PPAs about a week before I first posted here (June 17). I just checked my /etc/apt/
Chris (syphist) wrote : | #56 |
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-
Michael Kogan (michael-kogan) wrote : | #57 |
@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 : | #58 |
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) wrote : | #59 |
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) wrote : | #60 |
…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) wrote : | #61 |
To illustrate an other side-effect :
coeurnoir@Asgard:~$ deja-dup --backup
** (deja-dup:2774): WARNING **: AssistantOperat
Eberhard Beilharz (ermshiperete) wrote : | #62 |
I could work around this problem by uninstalling dbus-user-session (and its dependendants xdg-desktop-portal and xdg-desktop-
Thanks to Olaf who brought me on the right track (https:/
markuslet (markuslet) wrote : | #63 |
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/
* logout/login was not sufficient to see this solved. Full reboot was required.
redman (patrick-libert) wrote : | #64 |
Finally, this fixed the problem.
redman (patrick-libert) wrote : | #65 |
Thanks for everyone who helped
513G3 (513g3) wrote : | #66 |
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 : | #67 |
Thanks all!
I uninstalled my flatpak apps, flatpak, and dbus-user-
$ flatpak list
$ flatpak --system uninstall com.xamarin.
$ flatpak --system uninstall org.freedesskto
$ sudo apt-get remove --purge dbus-user-session
$ sudo apt-get remove --purge flatpak
$ sudo apt-get autoremove
$ sudo reboot
Mike Rushton (leftyfb) wrote : | #68 |
Removing dbus-user-session resolved my issue. It got added when I temporarily installed anbox. There was no xdg-desktop-portal or xdg-desktop-
Antonios Hadjigeorgalis (antonioshadji) wrote : | #69 |
- I think the issue started after this upgrade Edit (5.2 KiB, text/plain)
Removing flatpak/
flatpak list
org.pitivi.
org.gnome.
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-
apt-get purge dbus-user-session
reboot and check for running gnome-keyring-
$ psa | grep gnome-keyring-
antonios 4592 0.0 0.0 14524 980 pts/17 S+ 13:58 0:00 | \_ grep gnome-keyring-
lightdm 1589 0.0 0.0 123296 3148 ? Sl 13:56 0:00 /usr/bin/
antonios 2652 0.1 0.2 232048 34776 ? SLl 13:57 0:00 /usr/bin/
the lightdm owned process stopped running after a few minutes.
to workaround, I still have to run
`gnome-
Mike Rushton (leftyfb) wrote : | #70 |
@antonioshadji
I had to undo the workarounds in order for it to stop asking for passwords at login:
In /etc/xdg/
I originally replaced:
Exec=/usr/
with
#Exec=/
Some people put a new gnome-keyring startup file in ~/.config/
Remove that.
Then a complete reboot.
Antonios Hadjigeorgalis (antonioshadji) wrote : | #71 |
Thank you, @leftyfb.
I'm seeing some strange behavior when deleting the files in ~/.config/
I can delete the file. If I open the GUI for startup Applications it has a line for gnome-keyring-
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-
They contain:
Exec=/usr/
the rest of these three files are the same and contain the following lines:
OnlyShowIn=
X-GNOME-
X-GNOME-
X-GNOME-
X-GNOME-
X-GNOME-
X-GNOME-
X-GNOME-
NoDisplay=true
Antonios Hadjigeorgalis (antonioshadji) wrote : | #72 |
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-
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 : | #73 |
All I have running is /usr/bin/
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 : | #74 |
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-
- Revert files in `/etc/pam.d` back to their original state. I had commented out a line in `/etc/pam.
- 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 : | #75 |
I can confirm that removing the dbus-user-session and reverting a workaround (calling the gnome-keyring-
Eric Alzheimer (ealzheimer) wrote : | #76 |
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) wrote : | #77 |
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) wrote : | #78 |
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) wrote : | #79 |
Same here. Uninstalling dbus-user-session solved the issue.
Thanks to all contributors.
jose (jose-cybergalvez) wrote : | #80 |
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 : | #81 |
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-
jose (jose-cybergalvez) wrote : Re: [Bug 1689825] Re: gnome-keyring not unlocked on boot | #82 |
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-
> etc.
>
Byte Commander (bytecommander) wrote : Re: gnome-keyring not unlocked on boot | #83 |
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 : | #84 |
An easy workaround, while waiting a fix, is to add a startup application with this command
/usr/bin/
You will be required to re-enter the password once logged, but it should work.
David Spoelstra (davids-mediamachine) wrote : | #85 |
$ sudo apt-get remove --purge dbus-user-session
followed by a reboot fixed it!
Matteo Capobianco (m-capobianco) wrote : | #86 |
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.
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-
I eventually found that it came from a CUPS configuration file (/etc/cups/
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 : | #88 |
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 : | #89 |
I can confirm as well that removing dbus-user-session and reboot worked like a charm. Thx all.
Chigozirim Chukwu (eugenerjones) wrote : | #90 |
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 : | #91 |
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:/
$ 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-0alexlarss
Reverse Depends: xdg-desktop-
xdg-desktop-portal
Reverse Depends: xdg-desktop-
xdg-desktop-
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 : | #92 |
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 : | #93 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in dbus (Ubuntu): | |
status: | New → Confirmed |
Eric Carroll (eric-carroll) wrote : | #94 |
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-
I did stop the long pause on chrome using a workaround found https:/
by setting up ~/.config/
This still leaves me being prompted to unlock the keyring, which was not happening in 16.04.2
Eric Carroll (eric-carroll) wrote : | #95 |
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 : | #96 |
Uninstalling polychromatic, razer-daemon, and then dbus-user-session resolved the chrome problem.
Rocko (rockorequin) wrote : | #97 |
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) wrote : | #98 |
Rocko, please file a different bug for that issue.
Jeremy Bícha (jbicha) wrote : | #99 |
Eric, please contact the distributor/
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 : | #100 |
This bug was not only related to Flatpak. I have never installed/
Launchpad Janitor (janitor) wrote : | #101 |
Status changed to 'Confirmed' because the bug affects multiple users.
affects: | dbus → meta-gnome3 (Ubuntu) |
Changed in meta-gnome3 (Ubuntu): | |
status: | New → Confirmed |
Jeremy Bícha (jbicha) wrote : | #102 |
Mike, what is the output of this command:
apt rdepends dbus-user-session
no longer affects: | meta-gnome3 (Ubuntu) |
Mike Rushton (leftyfb) wrote : | #103 |
$ 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 : | #104 |
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:/
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 : | #105 |
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/
[4151:4181:
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:
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:
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 : | #106 |
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) wrote : | #107 |
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) wrote : | #108 |
Reinstalling the ca-certificates did not work for me.
Only removing dbus-user-session works around the problem for me.
Eric Carroll (eric-carroll) wrote : | #109 |
Also, openrazer & polychromatic no longer have the dependency on dbus-user-session. Thanks to the maintainers of these packages.
ipkpjersi (ipkpjersi) wrote : | #110 |
Any update on this issue? I do not feel comfortable removing dbus-user-session as a workaround, and I have simply added --password-
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) wrote : | #111 |
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) wrote : | #112 |
> 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) wrote : | #113 |
> 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) wrote : | #114 |
> 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) wrote : | #115 |
- I'm seeing slow downs.
- I'm not using automatic login.
Olivier Tilloy (osomon) wrote : | #116 |
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-
Thanks in advance!
Stephen M (yourjunkhere14) wrote : | #117 |
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) wrote : | #118 |
Running "chromium-browser --enable-
$ chromium-browser --enable-
ATTENTION: default value of option force_s3tc_enable overridden by environment.
I'm also running the gnome-keyring-
** (gnome-
** 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) wrote : | #119 |
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-
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:
Stephen M (yourjunkhere14) wrote : | #120 |
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) wrote : | #121 |
I still experience this bug in 18.04.
Jeremy Bícha (jbicha) wrote : | #122 |
Billy, please file a new bug for your issue with specific details about what you're experiencing.
Adrian Wilkins (adrian-wilkins) wrote : | #123 |
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-
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) wrote : | #124 |
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-
Daniele Besana (WP-OK) (daniele-wpok) wrote : | #125 |
Hi guys,
This bug is still present on latest versions (seahorse 3.30).
Why is assigned to chromium-browser package?
James Tunnicliffe (dooferlad) wrote : | #126 |
As with comment #107, `sudo apt-get install --reinstall ca-certificates` was the only fix for me. Removing/
Ramón Casero (rcasero) wrote : | #127 |
This also happens in disco dingo (19.04). Only solution is running `gnome-
Uninstalling `dbus-user-session` or doing `sudo apt-get install --reinstall ca-certificates` doesn't do anything.
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