chrome-browser makes gnome-keyring-daemon use 100% cpu

Bug #1174162 reported by MNLipp
460
This bug affects 110 people
Affects Status Importance Assigned to Milestone
Chromium Browser
Unknown
Unknown
chromium-browser (Ubuntu)
Fix Released
High
Unassigned
gnome-keyring (Ubuntu)
Fix Released
High
Unassigned

Bug Description

After upgrading to 13.04, when starting the chromium browser, the gnome-keyring-daemon runs at full CPU load and the chromium-browser has no access to the stored passwords.

The issue seems to be known (https://code.google.com/p/chromium/issues/detail?id=98601). I'm personally a bit surprised that Ubuntu 13.04 was released with such a serious problem.

The frequently proposed workaround (e.g. https://plus.google.com/110130355317073712944/posts/PckhFj5HUn4) doesn't work because (a) there is no .gnome2/keyrings any more and (b) it's rather inresponsible to store your passwords unencryted.

I found that killing gnome-keyring-server several times eventually gives you a working system.
---
ApportVersion: 2.9.2-0ubuntu8
Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: mnl 18759 F.... pulseaudio
CRDA:
 country DE:
  (2400 - 2483 @ 40), (N/A, 20)
  (5150 - 5250 @ 40), (N/A, 20), NO-OUTDOOR
  (5250 - 5350 @ 40), (N/A, 20), NO-OUTDOOR, DFS
  (5470 - 5725 @ 40), (N/A, 26), DFS
DistroRelease: Ubuntu 13.04
HibernationDevice: RESUME=UUID=86292e17-edd2-4a1b-8e1b-5208a1731140
InstallationDate: Installed on 2010-11-10 (900 days ago)
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
MachineType: Hewlett-Packard HP Compaq 6730b (GB990EA#ABD)
MarkForUpload: True
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-19-generic root=UUID=cff10fb4-08a2-459b-be12-80698b20d2d3 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.8.0-19.29-generic 3.8.8
RelatedPackageVersions:
 linux-restricted-modules-3.8.0-19-generic N/A
 linux-backports-modules-3.8.0-19-generic N/A
 linux-firmware 1.106
Tags: raring
Uname: Linux 3.8.0-19-generic i686
UpgradeStatus: Upgraded to raring on 2013-04-28 (0 days ago)
UserGroups: adm admin cdrom dialout libvirtd lpadmin plugdev sambashare voice wireshark
WifiSyslog: Apr 29 07:28:34 lipp-nb wpa_supplicant[1803]: wlan0: WPA: Group rekeying completed with c0:25:06:24:93:e1 [GTK=CCMP]
dmi.bios.date: 12/07/2011
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 68PDD Ver. F.20
dmi.board.name: 30DD
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 96.23
dmi.chassis.asset.tag: CNU9326SJY
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr68PDDVer.F.20:bd12/07/2011:svnHewlett-Packard:pnHPCompaq6730b(GB990EA#ABD):pvrF.20:rvnHewlett-Packard:rn30DD:rvrKBCVersion96.23:cvnHewlett-Packard:ct10:cvr:
dmi.product.name: HP Compaq 6730b (GB990EA#ABD)
dmi.product.version: F.20
dmi.sys.vendor: Hewlett-Packard

Revision history for this message
MNLipp (mnl) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected raring
description: updated
Revision history for this message
MNLipp (mnl) wrote : BootDmesg.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : CurrentDmesg.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : HookError_cloud_archive.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : IwConfig.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : Lspci.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : Lsusb.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : ProcEnviron.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : ProcInterrupts.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : ProcModules.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : PulseList.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : RfKill.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : UdevDb.txt

apport information

Revision history for this message
MNLipp (mnl) wrote : UdevLog.txt

apport information

Revision history for this message
MNLipp (mnl) wrote :

Bug #939301 is related, but it refers to a developer version of chrome-browser and has therefore not been considered seriously. So please don't make this a duplicate of the old bug, else no one will pay attention to it.

Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
affects: linux (Ubuntu) → chromium (Ubuntu)
Changed in chromium (Ubuntu):
status: Confirmed → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in chromium (Ubuntu):
status: New → Confirmed
Revision history for this message
Gabe Gorelick (gabegorelick) wrote :

Moving to correct package.

affects: chromium (Ubuntu) → chromium-browser (Ubuntu)
Revision history for this message
Harald Glatt (hachre) wrote :

I am experiencing this problem too, even with Googles Chrome packages for Ubuntu. This worked on release of Ubuntu 13.04 but an update in the following days broke it. I don't know which update, however.

I have noticed that if you let gnome-keyring-daemon run for 20 minutes the CPU usage eventually goes down and things start working normally...

Revision history for this message
Ldardini (ldardini) wrote :

I am experiencing this problem too, but I have made some tests and checks and maybe a workaround is available. I have verified while the gnome-keyring is at 100%, google chorme is recovering the stored password from Google and storing into the keyring, like they were absent. It seems google chrome was unable to use the previously stored one and pull all again from Google. I have enabled the automatic login and when google chrome starts, it asks for the password to unlock the keyring. Just avoid that and start google chrome after you have already unlocked the keyring, maybe just terminating your session and logging again with the password, skipping the automatic login.

Revision history for this message
Luke (lukebenes) wrote :

@Ldardini (ldardini)
Have you had any luck finding a work around? None of the ideas here or over at https://code.google.com/p/chromium/issues/detail?id=98601 have worked for me.

Chrome Version 39.0.2171.95
$ lsb_release -rcd ; uname -rm
Description: Ubuntu 14.04.1 LTS 3.13.0-43-generic i686

Revision history for this message
Vancouverite (sethgilchrist) wrote :

Is this a problem with GNOME keyring or Chrome/Chromium?

Is there a way that I can use the KDE password storage from within Unity instead of the GNOME Keyring so that I can still encrypt my passwords, but avoid this issue?

Revision history for this message
Bernhard Zürn (bernhard-zuern) wrote :

I can reproduce the problem with chrome but i cannot reproduce it with chromium ... strange ...

Revision history for this message
Harmen (harmenstoppels) wrote :

I still have this issue

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

affects: gnome-keyring → gnome-keyring (Ubuntu)
Changed in gnome-keyring (Ubuntu):
status: New → Confirmed
Changed in chromium-browser (Ubuntu):
importance: Undecided → High
Changed in gnome-keyring (Ubuntu):
importance: Undecided → High
Changed in gnome-keyring (Ubuntu):
status: New → Confirmed
Revision history for this message
Anmar Oueja (anmar) wrote :

FYI. the way I fixed this was to remove the keyring subdirs from .cache and .local/share and reboot.

Revision history for this message
Biji (biji) wrote :

You will lost passwords if you do

Revision history for this message
Karol Pucyński (kpucynski) wrote :

I have this problem only on Ubuntu with automatic login. Even ater whiping out password db ad recreating it.
The same database makes no problem when I have to enter password before login...

Revision history for this message
Scott Stensland (scottstensland) wrote :

This issue just happened to me again ubuntu 16.04 ... although not specific to that release as it happens on earlier releases too

 ... it was after changing my Google password
... I then needed to reboot for another reason
 ... after boot I then launched Chrome browser Version 50.0.2661.11 dev (64-bit) and then noticed very high CPU usage

 ... on Chrome browser top right of menubar was a yellow triangle
 ... I clicked it and was prompted to login to Google

 ... after this login the high CPU usage immediately stopped

Revision history for this message
skater ska (alternative-xen) wrote :

In my case, ubuntu LTS 14.04, i just turn off "automatic login" for user ubuntu login and then after that the gnome-keyring daemon go smooth...

Revision history for this message
JEMYZHANG (jemy-zhang) wrote :

for me, ubuntu 1604, Google login expired, and I just login to google account again in chrome, problem solved.

Revision history for this message
Petar Bojovic (petar-bojovic-paxy) wrote :

Ugly fix:
Remove gnome-keyring execute privilege.

chmod -x /usr/bin/gnome-keyring-daemon

After this, gnome-keyring-daemon will not make any Chrome issue anymore, but it will not save any system password (google chrome password will be saved and you can used saved one too).

Revision history for this message
owise1 (o-wise-1) wrote :

I found that stopping the gnome-keyring process resulted in the PC running normally again until the screen lock came on. This resulted in been unable to unlock the screen again requiring dropping to a command line via Ctrl + Alt + F1 to allow a reboot.

Therefore does Petar Bojovic's ugly fix cause the same issue?

Revision history for this message
pEEf (p4l) wrote :

This has been occurring for me now for several years. I have a large amount of passwords stored in chrome. The high CPU usage never really stops completely, as well as anytime chrome tries to retrieve a password, I have to wait about 10 seconds.

The fix is to rename the gnome-keyring-daemon which disables it and chrome then uses internal storage which is no problem. I'm aware I lose all secure storage this way, but it's intolerable otherwise.

Background: I probably have close to 1000 passwords stored. I use a passphrase to encrypt them on google's side.

Also: When gnome-keyring-daemon is running, any attempt to view stored passwords in the chrome settings screen results in a gray color for the entire dialog with no text visible.

Revision history for this message
owise1 (o-wise-1) wrote :

On my system this bug appears to have been resolved since Chromium updated to Version 53.0.2785.143. I note that when I boot up the system, at the log-in screen that I get a dialogue box requesting the wireless network password which has not occurred in the past so not sure if something has also changed with gnome-keyring.

Revision history for this message
calexil (calexil) wrote :

this seems resolved, but a new issue has arisen in it's place and may be related:

https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1642413

Revision history for this message
Oleksandr Zahorulia (hast4656) wrote :

Any news on this one? I still have this issue.

Revision history for this message
Frank Baehnisch (fbhnisch) wrote :

Here too, Chromium 56.0.2924.76, Ubuntu 16.04

Revision history for this message
Olivier Tilloy (osomon) wrote :

There is an upstream plan to trim the dependency of chromium on gnome-keyring to a bare minimum, see https://bugs.chromium.org/p/chromium/issues/detail?id=571003.

Revision history for this message
Tanel Tammik (keevitaja) wrote :

Btw this is affecting also Electron (https://electron.atom.io/) apps which try to log you in on Launch. For example Slack-Desktop.

Revision history for this message
Dimka (sze.td) wrote :

Here the same
Chrome Version 60.0.3112.113 (Offizieller Build) (64-Bit)

Revision history for this message
Mike Durham (mdurhamesq) wrote :

This drove me crazy on Ubuntu distros so I switched to Mint. It never happens on Mint, I wonder why?

Revision history for this message
Billy Braga (billybraga) wrote :

I experience this with Chrome 63 beta and Ubuntu 16.04 all up to date as of today.

Revision history for this message
pEEf (p4l) wrote :

For the last few YEARS, I fix this by adding "--password-store=basic" to the command line. It's "insecure credential storage", but it greatly speeds up Chrome password login and no high CPU utilization.

Simply edit /usr/share/applications/google-chrome.desktop, and add --password-store=basic to the 3 Exec= lines in that file.

Revision history for this message
Morteza (m-ziaeemehr) wrote :

I have this issue on chrome Version 62.0.3202.62 and Mint Mate 17.3

Revision history for this message
gido_b@yahoo.com (gido-b) wrote :

I also confirm this bug is still present in Ubuntu 17.10, on both Chrome and Chromium.

Revision history for this message
Jesse Glick (jesse-glick) wrote :

I see this from time to time, according to no apparent pattern. I will just suddenly hear my laptop fan come on, and from running `top` will see `gnome-keyring-daemon` consuming 60–80% CPU, along with some CPU from `chromium-browser`. The problem seems to go away on its own after a while.

Disabling keyring integration in Chromium is not a viable workaround for me; this feature was in fact a “key” reason I switched from Firefox.

Currently running Xubuntu 17.10 with all updates. I have 800+ passwords in the store acc. to `secret-tool search --all scheme 0 2>&1 | fgrep label | wc -l`, not synched with a Google account.

Revision history for this message
William Crandell (crandellws) wrote :

What worked for me was `gnome-keyring-daemon-old`

though

`google-chrome --password-store:basic` may work according to:

https://andreafortuna.org/chrome/how-to-prevent-the-huge-cpu-usage-of-gnome-keyring-daemon-when-starting-google-chrome/

Revision history for this message
Scott Stensland (scottstensland) wrote :

on Ubuntu 17.04 am seeing high CPU upon launching Chrome 63.0.3239.70-1
however after about 60 seconds it finishes and CPU usage returns to normal

Revision history for this message
Jesse Glick (jesse-glick) wrote :

I think I have tracked this down to irccloud.com, an app offering web access to IRC channels once you are logged in. I had that site open in a tab, among others, and saw `gnome-keyring-daemon` acting up. Closed `chromium` and `gnome-keyring-daemon` stopped working. Restarted `chromium` with the same tabs—daemon started working again. I tried restarting with progressively fewer tabs open, and it was restarting with irccloud.com closed that caused the problem to cease. Conversely, opening a tab with irccloud.com again causes the daemon to work. Not sure what about that site specifically would trigger a bug like this; GMail, etc. do not.

Revision history for this message
Nelson Elhage (nelhage) wrote :

I am also seeing this bug, and am also an irccloud.com user. I can confirm that if I refresh the IRCCloud tab, I see g-k-d spamming 100% CPU for a minute or so thereafter.

I found https://bugs.chromium.org/p/chromium/issues/detail?id=777206 which is a similar-ish bug about *chrome* CPU usage on IRCCloud that suggests that IRCCloud might have a large number of hidden password forms for some reason.

Revision history for this message
Jan Smith (johsmi9933) wrote :

I am seeing this and not an irccloud.com user.
On my 18.04 system with latest updates installed as of today, gnome-keyring-daemon used up about 75-100% of CPU for more than 5 minutes (with one chrome window open that had 6 tabs restored).

Revision history for this message
christopherreay (christopherreay) wrote :

I am having this problem. It started... yesterday? I just created a completely new, blank browser profile, and it literally cant start due to gnome-keyring "stuff".

its ransacking my machine.

I cant... believe this has been going on for years. I write code all day, and the sheer level of *work* it takes to blow a processor up to 100% usage is enormous. Whatever is actually happening is clearly *completely wrong*.

Is there a solution? Are people who write this code just fed up with trying to answer? Is there a thread that shows moving foward?

thank you

christopher

Revision history for this message
Olivier Tilloy (osomon) wrote :

Can you open chrome://password-manager-internals/ in a tab, save the contents of the log and share it after you reproduce the issue?

Revision history for this message
Paul White (paulw2u) wrote :

Olivier, I also suffer from this bug several times a day especially when I am using IRCCloud but tonight I opened the Ubuntu Wiki in a third tab and the CPU usage for gnome-keyring-daemon immediately rose to around 62% and stayed there for over a minute.

I'm attaching a log as you requested above which I let run until the CPU usage fell back to an acceptable level.

I'm using Ubuntu 18.04 and Chromium 68.0.3440.106.

Revision history for this message
Boris Gjenero (boris-gjenero) wrote :

This never happened in 18.04, and started happening after upgrading to 18.10. The keyring daemon when taking 100% CPU on one core also seems to hang and not respond to applications. I've had Chrome hang on startup, and I've had ssh and scp hang.

Revision history for this message
Scott Stensland (scottstensland) wrote :

Same very high CPU on Ubuntu 19.04 just
after I installed, launched and logged into gmail
using browser chrome Version 73.0.3679.0 (Official Build) dev (64-bit)

After 5 mins

/usr/bin/gnome-keyring-daemon --daemonize --login

no longer used high CPU

Revision history for this message
BlueT - Matthew Lien - 練喆明 (bluet) wrote :

An hour ago I've just had Chromium upgraded to 73.0.3683.86 (Official) Built on Ubuntu , running on Ubuntu 16.04 (64 bit). And this started happening.

Changed in chromium-browser (Ubuntu):
status: Confirmed → Fix Released
Changed in gnome-keyring (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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