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

Bug #1174162 reported by MNLipp on 2013-04-29
This bug affects 110 people
Affects Status Importance Assigned to Milestone
Chromium Browser
chromium-browser (Ubuntu)
gnome-keyring (Ubuntu)

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 ( I'm personally a bit surprised that Ubuntu 13.04 was released with such a serious problem.

The frequently proposed workaround (e.g. 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
 /dev/snd/controlC0: mnl 18759 F.... pulseaudio
 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
 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] 12/07/2011
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 68PDD Ver. F.20 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: HP Compaq 6730b (GB990EA#ABD)
dmi.product.version: F.20
dmi.sys.vendor: Hewlett-Packard

MNLipp (mnl) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected raring
description: updated
MNLipp (mnl) wrote : BootDmesg.txt

apport information

MNLipp (mnl) wrote : CurrentDmesg.txt

apport information

apport information

MNLipp (mnl) wrote : IwConfig.txt

apport information

MNLipp (mnl) wrote : Lspci.txt

apport information

MNLipp (mnl) wrote : Lsusb.txt

apport information

MNLipp (mnl) wrote : ProcCpuinfo.txt

apport information

MNLipp (mnl) wrote : ProcEnviron.txt

apport information

apport information

MNLipp (mnl) wrote : ProcModules.txt

apport information

MNLipp (mnl) wrote : PulseList.txt

apport information

MNLipp (mnl) wrote : RfKill.txt

apport information

MNLipp (mnl) wrote : UdevDb.txt

apport information

MNLipp (mnl) wrote : UdevLog.txt

apport information

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.

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

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

Changed in chromium (Ubuntu):
status: New → Confirmed
Gabe Gorelick (gabegorelick) wrote :

Moving to correct package.

affects: chromium (Ubuntu) → chromium-browser (Ubuntu)
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...

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.

Luke (lukebenes) wrote :

@Ldardini (ldardini)
Have you had any luck finding a work around? None of the ideas here or over at 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

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?

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

Harmen (harmenstoppels) wrote :

I still have this issue

Launchpad Janitor (janitor) wrote :

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

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

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

Biji (biji) wrote :

You will lost passwords if you do

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

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

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

JEMYZHANG (jemy-zhang) wrote :

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

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

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?

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.

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.

calexil (calexil) wrote :

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

Oleksandr Zahorulia (hast4656) wrote :

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

Frank Baehnisch (fbhnisch) wrote :

Here too, Chromium 56.0.2924.76, Ubuntu 16.04

Olivier Tilloy (osomon) wrote :

There is an upstream plan to trim the dependency of chromium on gnome-keyring to a bare minimum, see

Tanel Tammik (keevitaja) wrote :

Btw this is affecting also Electron ( apps which try to log you in on Launch. For example Slack-Desktop.

Dimka ( wrote :

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

Mike Durham (mdurhamesq) wrote :

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

Billy Braga (billybraga) wrote :

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

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.

Morteza (m-ziaeemehr) wrote :

I have this issue on chrome Version 62.0.3202.62 and Mint Mate 17.3 (gido-b) wrote :

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

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.

William Crandell (crandellws) wrote :

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


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

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

Jesse Glick (jesse-glick) wrote :

I think I have tracked this down to, 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 closed that caused the problem to cease. Conversely, opening a tab with again causes the daemon to work. Not sure what about that site specifically would trigger a bug like this; GMail, etc. do not.

Nelson Elhage (nelhage) wrote :

I am also seeing this bug, and am also an 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 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.

Jan Smith (johsmi9933) wrote :

I am seeing this and not an 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).

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


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?

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.

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.

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

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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