Description of problem: After the recent update to gnome-online-accounts, kerberos auth doesn't take place for a kerberos account on login. On executing kinit manually, cpu usage of the gnome-online-accounts process shoots up to 100%. Killing the process doesn't seem to hurt anything. gnome-online-accounts-3.8.3-1.fc19.x86_64
So, 3.8.3 tries to address: - https://bugzilla.gnome.org/show_bug.cgi?id=699491 - https://bugzilla.gnome.org/show_bug.cgi?id=705395 I think the CPU usage issue is similar to the one in 705395. I saw it happen once to me and the backtrace suggested so, but haven't been able to reproduce since then. I will try reproducing it your way using manual kinit. The others look similar to the latest comment in 699491. In short, some issues were fixed which unearthed some more.
The last two times I've run kinit, I've seen goa-daemon go to 100% cpu; I can't say with confidence that it's 100% reproducible for me, but it looks that way. If there's info I can gather for you, let me know.
Seeing the same issue (goa-daemon -> 100% cpu) with this ver/release. I don't always manually kinit, but when I do, the problem does not occur. Seems to happen when unlocking the screen (perhaps during tgt renewal?)
I just watched carefully to see when I see this behavior. The following steps reproduce it for me: 1) boot machine 2) login 3) manually kinit 4) start kerberized offlineimap goa-daemon is normal until the offlineimap command, at which point it goes to 100% cpu.
Raising severity to high as this is 100% reproducible for me and I have to kill goa-daemon every time I log in. This is so not my area of expertise, but attaching to goa-daemon with gdb shows it seems to be in this codepath most of the time. If this is not helpful, sorry and let me know what information I can gather. (gdb) bt #0 0x0000003ea9e6f5ea in g_time_zone_new () from /lib64/libglib-2.0.so.0 #1 0x0000003ea9e31c1b in g_date_time_new_now_local () from /lib64/libglib-2.0.so.0 #2 0x00000000004136d2 in fire_or_rearm_alarm () #3 0x0000000000413bf2 in on_timer_source_ready () #4 0x0000003ea9e47e06 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #5 0x0000003ea9e48158 in g_main_context_iterate.isra.22 () from /lib64/libglib-2.0.so.0 #6 0x0000003ea9e4855a in g_main_loop_run () from /lib64/libglib-2.0.so.0 #7 0x00000000004086e2 in main () (gdb)
I have the same problem. I am using kinit to acquire TGT. After getting ticket this way, goa-daemon was consuming one whole core. I am also using evolution as a mail client. As an authentication mechanism I was using GSSAPI, therefore Kerberos. Killing goa-daemon had no effect. When it started again, it took one whole core again. Once I changed auth mechanism in evolution and killed goa-daemon, everything was okay. I can provide more details if needed.
Created attachment 795989 [details] output of gdb thread apply all bt full Two additional datapoints: first, not surprisingly, cpu utilization goes to 100% on first use of the ticket regardless of service, it's not related to offlineimap. Second, I talked to halfline yesterday on irc, and he recommended that I attach the output of thread apply all bt full, so here it is.
I think bug #1005619 and bug #1006267 are dupes of this... Is it possible to just get GNOME to ignore my kerberos account? I have that configured with sssd, so I don't think GOA is actually giving me anything. But when I tried simply removing the account from GOA settings, it comes back after the next login or kinit. I also notice that the GNOME Keyring is littered with a bunch of "GOA kerberos credentials for identity account_123456789". That number varies, but the stored passwords are all the same, though not my actual kerberos password.
My assumption is this is a side-effect of the patch in https://bugzilla.gnome.org/show_bug.cgi?id=699491 which accesses things from the wrong thread. I've posted some more details there and reopend that bug. hopefully when we fix it this problem will go away.
sorry to add confusion i actually meant https://bugzilla.gnome.org/show_bug.cgi?id=705395
Note that this is likely a dup of bug 1005619, which has a bit more backtrace info.
gnome-online-accounts-3.8.3-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/gnome-online-accounts-3.8.3-3.fc19
Package gnome-online-accounts-3.8.3-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnome-online-accounts-3.8.3-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-17920/gnome-online-accounts-3.8.3-3.fc19 then log in and leave karma (feedback).
gnome-online-accounts-3.8.3-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1012935 has been marked as a duplicate of this bug. ***