[arm] gnome-keyring-daemon eating 100% CPU at login in Jaunty

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in gnome-keyring.
For future reference you might be interested to know that a lot of applications have bug reporting functionality built in to them. This can be accessed via the Report a Problem option in the Help menu for the application with which you are having an issue. You can learn more about this feature at https://wiki.ubuntu.com/ReportingBugs.

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a backtrace following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

that's not a gnome-session issue

So I'm told this happens on all ARM boards which Jerone is using.

Jerone, please attach with gdb and report the output of the backtrace command on all threads (see wiki page on debugging); also you could try stracing g-kr.

Thanks,

This problem still exists after a fresh build of jaunty for ARM with the "ubuntu-desktop" package as of Feb 25 09. I will get the debugging info out tommorow.

To recreate this is super simple. Have a fresh install and login as a new user to the ubutu (gnome) desktop. You will see it crawl while trying to load .. it's because the gnome-keyring-daemon is eating up all the CPU.

> To recreate this is super simple. Have a fresh install and login as a new user to the ubutu (gnome) desktop. You will see it crawl while trying to load .. it's because the gnome-keyring-daemon is eating up all the CPU.

if that was that easy we would not be asking for details, that seems specific to the configuration or architecture you are using

i will try to reproduce it on the weekend on my arm hardware.
yes, it seems to only show up on arm systems.
i'll attach my findings and logs here

I may have a similar issue, so I'm not opening a new bug. Also, I have only vague info about it. Will search logs next time this happens.
I have this code that's doing scp over from a windows + cygwin machine. I have my id_rsa.pub authorized in this remote machine. Sometimes, seemingly randomly after a number of scp, the cpu would max at 100%, with gnome-keyring-daemon being the offender process. There is no real way out. I can kill gnome-keyring-daemon, but then my passwordless scp don't work anymore, and I can't restart gnome-keyring-daemon within the gnome session (can i?).

As I say, sorry for the lack of details. I will look into log files next time this happens.
Note that I am running the exact same things daily within ibex w/o any problems.

I landed here because of a similar issue. Maybe the same as Francois Rigaut describes.

It happens when doing ssh. I have ssh-agent running, which should supply the key to ssh. Some times setting up an ssh connection hangs. And the only solution to make ssh work again is to remove the environement variables that tell ssh to ask an agent for the keys.

Now this happened again, and I had a look at top and noticed gnome-keyring-daemon at 100%.

Next time I reboot I will have a look on gnome-keyring to see if it goes to 100% just in interaction with ssh/ssh-agent.

Is there any mean I can gather information useful to you to locate the problem?

$ lsb_release -dr
Description: Ubuntu jaunty (development branch)
Release: 9.04
$ uname -a
Linux garfield.inodes.ch 2.6.28-8-generic #26-Ubuntu SMP Wed Feb 25 04:28:54 UTC 2009 i686 GNU/Linux
$ apt-cache policy gnome-keyring
gnome-keyring:
  Installed: 2.25.91-0ubuntu1
  Candidate: 2.25.91-0ubuntu1
  Version table:
 *** 2.25.91-0ubuntu1 0
        500 http://ch.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

i still cant reproduce it on my arm systems, can you please try with the just uploaded 2.25.92-0ubuntu1, one upstream changelog entry of this version reads:

    - Fix problems when multiple processes tried to initialize the
      gnome-keyring-daemon at the same time, often resulting in a user
      session that hung on login.

that sounds quite similar to the original bug description ...

@oliver
         I will try it again with a fresh install today or tommorow. Others ARM partners have reported this isse with their fresh installs as well. On different ARM boards as well. Maybe it's fixed now in a recent update.

@oliver
          As of March 3 fresh install. The problem very much still exists. It has been reported on more then one ARM platform. I'm using babbage 1.0 with an SD card. I used your script:

sudo ./build-arm-rootfs -s ubuntu-desktop,openoffice.org -f ubuntu -l ubuntu -p ubuntu -i 4G

         When you login as users "ubuntu" you will notice the gnome menu never fully comes up. Just wait a minute. Switch over to virtual terminal. Run top and you will see gnome-keyring-daemon at the top of the CPU usage list.

         It's odd you did not see this. As I and other doing fresh installs imediately hit it.

yes, i use the same way to create my rootfs'es, though i only use the SD for booting, the rootfs comes from USB.
given that most of the other devs use the exact same setup (usb is simply faster than SD if you complie stuff) and apparently nobody in the team sees these issues, i would start to suspect it has something to do with the underlying media.
how do you format your SD ? what filesystem do you use ... it might also be a problem with the SD driver on the babbage. since we are likely to start building images soon i will test with different media and filesystems this week to see if its reproducable in different setups ...

The SD cards are formated ext2. I would say that this is an i/o case but seems like something more suttle may be going on.

Oh also all the other apps have no problems with i/o. That is more then likely not the case.

I have an SD card 8GB & 4GB both Sandisk Ultra that load everything fine. But gnome-keyring-daemon looses it's mind when loaded. But once killed all is well.

Here are the steps

1) Partition SD card
        1) 15MB unlocated
        2) rest rootfilesystem formatted ext2

2) build rootfs

3) untar rootfs to filesystem

4) edit fstab of rootfilesystm

5) sync and unmount disk

6) Boot and log in

I'm seeing this pretty consistant on different babbage boards.

I have a very similar problem on x86_64, gnome-keyring 2.25.92-0ubuntu1. Sometimes when I log in gnome-keyring-daemon is hung using 100% cpu. Sometimes it works for a while, then hangs when asked for a key by an ssh invocation. I've only had the problem since upgrading to jaunty last week.

Attaching with gdb I got the following backtrace:

(gdb) bt
#0 0x00007fed5df57496 in poll () from /lib/libc.so.6
#1 0x000000000046ebd0 in ?? ()
#2 0x00007fed5e44670f in ?? () from /usr/lib/libglib-2.0.so.0
#3 0x00007fed5e446d3d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#4 0x000000000040e4e7 in ?? ()
#5 0x00007fed5de995a6 in __libc_start_main () from /lib/libc.so.6
#6 0x000000000040dc89 in ?? ()
#7 0x00007fff67a59688 in ?? ()
#8 0x000000000000001c in ?? ()
#9 0x0000000000000003 in ?? ()
#10 0x00007fff67a5af2e in ?? ()
#11 0x0000000000000000 in ?? ()

Is there a work-around for this? My development environment is effectively unusable without an ssh key-agent, and since restarting a global agent requires logging out, I consider this a very serious issue.

the stacktrace has no debug informations

I'm aware of that. I thought the hang in poll() would be useful information even if you didn't have a symbol table for the package.

Is there a package with debug information I can install? Otherwise I'll try to build a version myself and see if it happens again.

@Ralph
      The work around for now is to stop the gnome-kering-daemon. To do this go to System->Prefrence->Startup Applications . Then uncheck Gnome Keyring Daemon. Then log out and log back in

@Jerone
        Thanks for the suggestion, but that leaves no agent running at all. I don't mind killing the thing, but I need a key agent which can be shared between multiple terminal windows, such as used to be provided by starting the session within ssh-agent.

Oops, ssh-agent is running, and the workaround does work for me. Sorry about that.

so digging on here on teh babbage board, it seems that with teh new kernel weher we actually have a working hwclock, setting the clock properly also fixes the gnome-keyring issue

does that mean this bug should be dropped as a release target, since it only manifests with a broken kernel?

no, my last comment was a red herring ... it still shows up but i'm to busay with image building atm and upstream asks for a plain build from source to verify, the bug is critical enough to be considered RC ... (setting to high for now)

btw, would be helpful if someone could produce a backtrace from a g-k-d source build on a babbge board, that would surely speed things up (so it doesnt have to wait until i get to it)

I've been working on this bug, and I've done a bisection of uploads of gnome-keyring to Jaunty. The bug only started occurring with the upload of 2.25.4.1; 2.25.1 and 2.24 are unaffected. I'm trying now to isolate the changeset that broke the daemon on ARM.

@Ralph, since all of the other reports in this bug are on arm systems, it's very possible that you have a different bug. Could you file it separately (use "ubuntu-bug /usr/bin/gnome-keyring") and mention the bug number here? Maybe it will turn out to be the same, but maybe not, and it's easier to dupe the second bug than to untangle this one.

For what it's worth, I use gnome-keyring-daemon pretty heavily on x86-64 and have never seen this happen once, so if there's a bug there, it seems MUCH less common than the ARM issue we're investigating here.

I've pushed a gnome-keyring building with -O1 on armel as that was said to workaround the bug by Michael no IRC.

@Michael: please document your debugging progress here, backtraces, what you tried etc.

I personally suspect http://bugzilla.gnome.org/show_bug.cgi?id=575247 to be on the right track and that cells are not properly inserted in the ring, but the patch seems to cause other breakages.

marking the jaunty task as wontfix and un-milestoning as we have a workaround in place. Of course a cleaner fix is a welcome replacement though.

The fix applied to close bug #338158 is confirmed not to fix this bug.

gnome-keyring-daemon hangs in --start and never forks to a --daemonize --login process
sockets for ssh and pkcs11 dont show up in the socket dir
running gnome-keyring-daemon --daemonize --login from a terminal does not result in 100% CPU usage but still leaves me without more than /tmp/keyring-*/socket

i tested with --start --components=ssh as well as --start --components=pkcs11, neither of them got further in the process so i assume its not the fault of the backend components

confirming that the rebuild with -O1 works around the issue

will be fixed with the 2.16.1 update once accepted today

This bug was fixed in the package gnome-keyring - 2.26.1-0ubuntu1

---------------
gnome-keyring (2.26.1-0ubuntu1) jaunty; urgency=low

  * New upstream version:
    - Fix many problems with the new secure memory allocator.
      (lp: #328167, #338158, #352269)
    - DBus now automatically starts the gnome-keyring service properly.
      (lp: #344444)
    - When auto activating the gnome-keyring DBus service, check for an
      already running daemon.
    - Don't print critical warnings when registering with DBus fails.
    - Bump glib dependency.
    - Add DBus method for getting the gnome-keyring environment variables.
      (lp: #345496)
    - Fix crash when prompting to unlock the keyring.
    - Initialize daemon with LOGNAME and USERNAME environment variables.
    - Build fixes
  * debian/patches/03_secure-mem_crash.patch:
    - the change is in the new version

 -- Sebastien Bacher <email address hidden> Mon, 13 Apr 2009 11:00:28 +0200

Verified fixed.

I confirmed that this issue is still present in gnome-keyring 2.26.1 if it is built with -O2. Further debugging information relayed upstream.

On Tue, Apr 14, 2009 at 12:59:28PM -0000, Steve Langasek wrote:
> ** Changed in: gnome-keyring (Ubuntu Jaunty)
> Status: Triaged => Won't Fix

Wasn't this fixed by

gnome-keyring (2.26.0-0ubuntu7) jaunty; urgency=low

  * Built with -O1 on armel to workaround a deadlock which is triggerred
    easily on armel; LP #328167.

 -- Loic Minier <email address hidden> Thu, 09 Apr 2009 09:58:08 +0200

?

--
 - mdz

On Tue, Apr 14, 2009 at 02:56:58PM +0100, Matt Zimmerman wrote:
> On Tue, Apr 14, 2009 at 12:59:28PM -0000, Steve Langasek wrote:
> > ** Changed in: gnome-keyring (Ubuntu Jaunty)
> > Status: Triaged => Won't Fix

> Wasn't this fixed by

> gnome-keyring (2.26.0-0ubuntu7) jaunty; urgency=low
>
> * Built with -O1 on armel to workaround a deadlock which is triggerred
> easily on armel; LP #328167.

> -- Loic Minier <email address hidden> Thu, 09 Apr 2009 09:58:08 +0200

> ?

This had been regarded as a workaround, with the bug left open for future
work to fix whatever underlying problem led to the -O1 requirement; I was
just putting the bug state back to where it was earlier, before the latest
upload that was thought to fix it.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I had uploaded g-k built with -O1 to workaround this bug in jaunty.

i revisited the issue today and tested the following:

 * we noticed that the issue does not show up in karmic so i rebuilt the 2.27 version of gnome keyring in jaunty, the issue returned with the newer version as well

 * i rebuilt the 2.27 source in jaunty with karmics gcc-4.4, the issue vanished

 * i rebuilt the 2.26 source in jaunty (dropping the workaround) with karmics gcc-4.4 and the issue vanished as well

i think we can start to assume that there is a compiler bug with gcc-4.3

setting to fix released status, the issue doesnt show up with recent upstream and gcc 4.4

I am seeing a similar behavior when trying to unlock on Karmic today. I had to kill the keyring daemon from the console (ctlr+alt+F1). I have seen it twice today. I am not sure it is relevant here.

Steps to reproduce:

1. Lock the screen - ctrl + alt + 'L'
2. Try to unlock the screen with possibly a wrong password.

I have not tried to reproduce the problem. Will do if needed when I boot next.

Hope this helps.

For what it's worth, I'm seeing this issue (100% CPU usage, Gnome desktop hangs completely on start) with Jaunty installed from http://old-releases.ubuntu.com/ubuntu/ , running in a chroot under Android on a Tegra2 tablet %).

Installing http://old-releases.ubuntu.com/ubuntu/pool/main/g/gnome-keyring/gnome-keyring_2.28.1-0ubuntu1_armel.deb (using dpkg -i --force-all) makes desktop not hang on start (like with 2.26.1-0ubuntu1), but gnome-keyring-daemon still eats 100% CPU.

So, "rm /etc/xdg/autostart/gnome-keyring-daemon.desktop" seems like good sh-friendly fix.