noromanba/gnome-keyring-daemon-use-100percent-cpu.mkd

Last active November 16, 2022 20:50

Star () You must be signed in to star a gist
Fork () You must be signed in to fork a gist

Learn more about clone URLs
Clone this repository at <script src="https://gist.github.com/noromanba/5793161.js"></script>
Save noromanba/5793161 to your computer and use it in GitHub Desktop.

Download ZIP

gnome-keyring use 100% CPU usage when Google Chrome started

Raw

gnome-keyring-daemon-use-100percent-cpu.mkd

gnome-keyring use 100% CPU usage when Google Chrome started

c.f.

Environment

OS: Knoppix 7.0.3 LCR
DE: LXDE

Chrome

google-chrome-stable .deb package

chrome://version

Google Chrome	27.0.1453.110 (Official Build 202711) 
OS	Linux 
WebKit	537.36 (@151310)

Chrome Sync

in use
works well before touch gnome-keyring checkbox
works well after KILL gnome-keyring processes

Sequence of events

What's the trigger? (prob gnome-keyring/libc SEGV)

start lxsession-edit in menu

open menu

check "SSH Key Agent" in "Automatically Started Applications" tab

Segmentation fault(SEGV)

SEGV in syslog

Jun 17 02:22:38 Microknoppix kernel: [ 8666.470367] lxsession-edit[8489]: segfault at bee8e454 ip b6c355bb sp bfaa0a80 error 4 in libc-2.13.so[b6bc7000+142000]

begin 100% CPU usage

when google-chrome started

htop hardcopy

  1  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]     Tasks: 103, 181 thr; 3 running
  2  [|||||                                                         5.8%]     Load average: 3.85 2.39 1.64 
  Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||571/3036MB]     Uptime: 10:24:57
  Swp[                                                          0/2277MB]

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command                                                                                   
 9839 knoppix    20   0 78976 37748  3816 R 100.  1.2  1:47.68 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

uncheck "SSH Key Agent"

no error yet, so press "OK"

Segmentation fault(SEGV) again

OMG. SEGV in syslog

Jun 17 02:37:18 Microknoppix kernel: [ 9546.463089] lxsession-edit[8531]: segfault at bee746b4 ip b6c745bb sp bff2b930 error 4 in libc-2.13.so[b6c06000+142000]

keyring zombie

unchecked "SSH Key Agent", but actual keep auto-start. so CPU usage 100% everytime when Chrome started

WTH

Temporally calm down

do sudo kill -9 KEYRING_PROC [, PROC_NUM ...], stability is back

after kill keyrings

htop hardcopy

  1  [||||                                                          4.6%]     Tasks: 102, 171 thr; 1 running
  2  [||                                                            2.6%]     Load average: 1.99 0.82 0.78 
  Mem[|||||||||||||||||||||||||||||||||||||||||||||||||       570/3036MB]     Uptime: 07:24:43
  Swp[                                                          0/2277MB]

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command                                                                                   
 9839 knoppix    20   0 59712 18336  3812 D  0.0  0.6  0:27.17 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

creepy...

packages / confs

gnome-keyring packages

knoppix@Microknoppix:~/.gnome2/keyrings$ aptitude versions gnome-keyring | grep -P '^i' -B 1 -A 2
Package gnome-keyring:
i   3.2.2-2                                                                 100 
p   3.4.1-5                                       stable,testing,unstable   990 
p   3.8.0-1                                       experimental              1   
--
Package libgnome-keyring-common:
i   3.4.1-1                                       stable,testing            990 
p   3.8.0-2                                       unstable                  500 

--
Package libgnome-keyring0:
i   3.4.1-1                                       stable,testing            990 
p   3.8.0-2                                       unstable                  500 

--
Package libpam-gnome-keyring:
i   3.4.1-4                                                                 100 
p   3.4.1-5                                       stable,testing,unstable   990 
p   3.8.0-1                                       experimental              1   
knoppix@Microknoppix:~/.gnome2/keyrings$

~/.gnome2/keyrings

knoppix@Microknoppix:~/.gnome2/keyrings$ ls -A
default  default.keyring

/etc/xdg/autostart

knoppix@Microknoppix:/etc/xdg/autostart$ ls -Al
total 40
-rw-r--r-- 1 root root 5070 Jan 26  2012 gnome-keyring-gpg.desktop
-rw-r--r-- 1 root root 6426 Jan 26  2012 gnome-keyring-pkcs11.desktop
-rw-r--r-- 1 root root 6036 Jan 26  2012 gnome-keyring-secrets.desktop
-rw-r--r-- 1 root root 4923 Jan 26  2012 gnome-keyring-ssh.desktop
-rw-r--r-- 1 root root 7018 Apr 28  2012 gsettings-data-convert.desktop
-rw-r--r-- 1 root root 4673 Mar 25  2012 nm-applet.desktop
-rw-r--r-- 1 root root  250 Sep  9  2011 notification-daemon.desktop
-rw-r--r-- 1 root root 4651 Nov 12  2011 polkit-gnome-authentication-agent-1.desktop
knoppix@Microknoppix:/etc/xdg/autostart$

knoppix@Microknoppix:/etc/xdg/autostart$ gview gnome-keyring-*
4 files to edit

:buffers
  1  h=  "gnome-keyring-gpg.desktop"    line 112
  2  h=  "gnome-keyring-pkcs11.desktop" line 116
  3 #h=  "gnome-keyring-secrets.desktop" line 115
  4 %a=  "gnome-keyring-ssh.desktop"    line 114
Press ENTER or type command to continue

dhensen commented Oct 9, 2015

I have this same issue under using latest chromium under arch linux. If you need me to output some log or verify stuff let me know.

tracker1 commented Oct 10, 2015

Same issue in latest ubuntu with latest chrome... it doesn't happen all the time, and seems to restart if I force kill the keyring execution... but settles down after a few minutes... it's kind of a pain that this has been a pretty significant bug for a couple years now.

joaoreis81 commented Nov 12, 2015

Same issue fedora 22 and latest chrome. after a wile it calms down cpu usage and everything goes nice.

davilima6 commented Feb 5, 2016

+1 here. Is there a proper issue?

charles-ritchie commented Feb 25, 2016

Same issue here. I get upto 1.3GB of RAM usage and 100% cpu usage for 10-20mins every so often after just 2 days uptime.
Chrome uses enough memory as is, gnome-keyring-daemon swallowing up 1.3GB additonal RAM is nearly killing my dev box when also using a windows VM.

ianherbert commented Mar 8, 2016

+1 for this. Overheats my machine running Ubuntu 15.10 and the gnome-keyring-daemon is using 98% CPU according to Top.

vakorovin commented Mar 17, 2016

aa6e commented Mar 19, 2016

Same issue here with Ubuntu 15.10, Chrome 49.0.2623.87 (64-bit)

martinv13 commented Apr 5, 2016

Same here with ubuntu 14.04.4
Anyone got a fix for that?

mkdizajn commented Jun 3, 2016

I'm sure this ain't the bug guys,, that's normal behaviour, because I think that we all have whoooole bunch of passwords saved inside our login file,, location on my box is: /home/USER/.local/share/keyrings/login.keyring I'm on xubundu 16LTS, find the file for your dist. if not there

you can do simple test like this:

close chrome
open terminal: mv login.keyring login.keyring.OLD

now open the chrome again and htop will show cpu 0% for gnome-keyring-daemon

so that means that we only need to lower the count of saved passwords inside keyring file :)

now I'm strugling with seahorse package that does not have mass delete option there :( if anyone have idea how to overcome that, please share it..

hth, kres

Paxy commented Jun 9, 2016

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

ssrublev commented Aug 19, 2016

I also have this problem with Yandex Browser (Chromium clone).

oliworx commented Apr 15, 2017 •

edited

Loading

Can't believe this is still an issue after several years!
Thanks Paxy, for for preventing an easy fix for this.

haydenjames commented Oct 15, 2017 •

edited

Loading

The fix is to install Chromium on Linux.
Then add the following to /etc/chromium.d/default-flags:

# Disable GNOME keyring (SLOW!)
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --password-store=basic"

This will also avoid gnome-keyring-daemon and use basic storage. :/ But fixes the 100% CPU and slow passwords issues.

If someone knows how to set the equivalent in Chrome then please ping me.

ssrublev commented Nov 27, 2017

I still have this with Yandex-browser in Fedora-MATE. Filed a request to Yandex-browser support. I now suspect it may be related to system locales.

ssrublev commented Nov 29, 2017

Yandex-browser support is usually very responsive to bugreports. But this particular report they seem to totally ingore. In the past I once filed another report on this that was also ignored.

Finally I again did -x to gnome-keyring-daemon. I thought it may cause browser not to remember passwords. But it seem to work well now without it. I don't know what problems and where it may cause in future.

DeadMate commented Dec 5, 2017

Same issue with ubuntu 17.10 and any other ubuntu-based distro.

dbrimley commented Dec 29, 2017 •

edited

Loading

@DeadMate right on, I'm getting this with ubuntu 17.10 as well.

diegofcv commented Jan 8, 2018

+1 here.
Debian 8 with Cinnamon.

ssrublev commented Jan 8, 2018

Yandex-browser support answered to me weeks later, acknowledged the issue and said they'd be looking at it some time.

billybraga commented Jan 20, 2018 •

edited

Loading

Same here (Ubuntu 16.04, Chrome beta 64). This seems the official thread : https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1689825?comments=all

I put this in a .sh file that runs in a chrome after updates :

sed -i 's/Exec=\/usr\/bin\/google-chrome-stable %U$/Exec=\/usr\/bin\/google-chrome-stable %U --password-store=basic/g' /usr/share/applications/google-chrome.desktop

sed -i 's/Exec=\/usr\/bin\/google-chrome-stable$/Exec=\/usr\/bin\/google-chrome-stable --password-store=basic/g' /usr/share/applications/google-chrome.desktop

slayer commented Feb 23, 2018

Same issue

kovinet commented Apr 25, 2018

toddhy commented Sep 2, 2018

I'm getting this too... can't believe it's not fixed by now.

oscx commented Feb 28, 2019

mohamedhagag commented May 19, 2019

4 yrs and no fix :| !

mort3za commented Jun 4, 2019

I have this problem in 2019 and chrome 74

baybal commented Dec 17, 2019

Fixed upstream https://gitlab.gnome.org/GNOME/gnome-keyring/merge_requests/5#note_339865

bokunodev commented Nov 3, 2022

still happen
it happen in the middle of long coding session. so annoying

Abdillah commented Nov 16, 2022

It is, @bokunodev, especially if you use 2.74 GLib.
That might be due to a GLib commit introduced 3 weeks ago, it has been fixed in 2.75.
https://gitlab.gnome.org/GNOME/glib/-/issues/2795

noromanba/gnome-keyring-daemon-use-100percent-cpu.mkd

gnome-keyring use 100% CPU usage when Google Chrome started

c.f.

Environment

Chrome

chrome://version

Chrome Sync

Sequence of events

start lxsession-edit in menu

Segmentation fault(SEGV)

begin 100% CPU usage

htop hardcopy

uncheck "SSH Key Agent"

Segmentation fault(SEGV) again

keyring zombie

Temporally calm down

after kill keyrings

htop hardcopy

packages / confs

gnome-keyring packages

~/.gnome2/keyrings

/etc/xdg/autostart

dhensen commented Oct 9, 2015

tracker1 commented Oct 10, 2015

joaoreis81 commented Nov 12, 2015

davilima6 commented Feb 5, 2016

charles-ritchie commented Feb 25, 2016

ianherbert commented Mar 8, 2016

vakorovin commented Mar 17, 2016

aa6e commented Mar 19, 2016

martinv13 commented Apr 5, 2016

mkdizajn commented Jun 3, 2016

Paxy commented Jun 9, 2016

ssrublev commented Aug 19, 2016

oliworx commented Apr 15, 2017 • edited Loading

haydenjames commented Oct 15, 2017 • edited Loading

ssrublev commented Nov 27, 2017

ssrublev commented Nov 29, 2017

DeadMate commented Dec 5, 2017

dbrimley commented Dec 29, 2017 • edited Loading

diegofcv commented Jan 8, 2018

ssrublev commented Jan 8, 2018

billybraga commented Jan 20, 2018 • edited Loading

slayer commented Feb 23, 2018

kovinet commented Apr 25, 2018

toddhy commented Sep 2, 2018

oscx commented Feb 28, 2019

mohamedhagag commented May 19, 2019

mort3za commented Jun 4, 2019

baybal commented Dec 17, 2019

bokunodev commented Nov 3, 2022

Abdillah commented Nov 16, 2022

oliworx commented Apr 15, 2017 •

edited

Loading

haydenjames commented Oct 15, 2017 •

edited

Loading

dbrimley commented Dec 29, 2017 •

edited

Loading

billybraga commented Jan 20, 2018 •

edited

Loading