RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1722210 - goa-daemon spams log file due to expired Kerberos logins when using KCM ticket cache (sssd-kcm)
Summary: goa-daemon spams log file due to expired Kerberos logins when using KCM ticke...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-online-accounts
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Debarshi Ray
QA Contact: Desktop QE
URL:
Whiteboard:
: 1724521 (view as bug list)
Depends On: 1601438 1774580
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-19 17:14 UTC by Joe Wright
Modified: 2024-06-13 22:09 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1601438
Environment:
Last Closed: 2020-08-27 15:41:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Joe Wright 2019-06-19 17:14:23 UTC 
+++ This bug was initially created as a clone of Bug #1601438 +++

Description of problem:

Gnome-online accounts creates a long list of expired "temporary logins" from kerberos logins that are not cleaned up, causing my logfile to be spammed by goa errors.


This is what my ~/.config/goa-1.0/accounts.conf looks like:

-------------------------------------------------------------
[Account account_1531739258_603]
IsTemporary=true
SessionId=8032df612956a6ef9e874c2d5b48c52e

[Account account_1531739266_604]
IsTemporary=true
SessionId=89e2991aae5283b72b2df7725b4c70b2

... Repeated 20 times ....

[Account account_1531739281_607]
IsTemporary=true
SessionId=89e2991aae5283b72b2df7725b4c70b2

[Account account_1531739701_691]
Provider=kerberos
Identity=akorsunsky
PresentationIdentity=akorsunsky
Realm=EXAMPLE.COM
SessionId=89e2991aae5283b72b2df7725b4c70b2
IsTemporary=true
TicketingEnabled=true
-------------------------------------------------------------


This causes the following errors in my journal to appear *twenty times*, *every single second*:

-------------------------------------------------------------
Jul 16 13:29:52 mymachine.example.com goa-daemon[3253]: Unsupported account type (null) for ID account_1531481542_37043 (no provider)
Jul 16 13:29:52 mymachine.example.com goa-daemon[3253]: goa_provider_get_for_provider_type: assertion 'provider_type != NULL' failed
Jul 16 13:29:52 mymachine.example.com goa-daemon[3253]: Unsupported account type (null) for identity (null) (no provider)
-------------------------------------------------------------

Please do the math on this one. Twenty times each second is 1200 times per minute, which is 72000 times per hour.
If I scroll through my logs, these messages is all I can see. Please send help.


Note that removing ~/.config/goa-1.0/accounts.conf helps temporary, but on reboot or new login it is recreated, starts filling up with these "IsTemporary=true" accounts, and then starts spamming my log again.

The issue is compounded by Bug 1379070: I don't even need GOA, I am perfectly happy without it. But I have no way of turning it off and no way of uninstalling it because it's a core dependency of all of the GNOME desktop.

For now it just keeps spamming my log files, but if we could come up with a fix or workaround, that would be really great.



Version-Release number of selected component (if applicable):
gnome-online-accounts-3.28.0-1.fc28.x86_64
gnome-online-accounts-3.28.0-1.el7.x86_64


How reproducible:
Every time

Steps to Reproduce:
1. Log in to my machine
2.
3.

Actual results:
Have my logs spammed


Expected results:
Not have my logs spammed


Additional info:

--- Additional comment from René Genz on 2018-08-17 08:03:00 UTC ---

Thank you for pointing me here. I have the same problem with a similar environment. For more information about how goa-daemon filled /tmp, see bug 1379070#c23 and a correction in 1379070#c25.


Alexander proposed a workaround how to disable goa at 1379070#c22

--- Additional comment from Alexander Korsunsky on 2018-12-11 15:13:09 UTC ---

This is still an issue in Fedora 29. In fact, when testing again I was greeted with about 300.000 messages within 10 minutes, because I forgot to clean out my  ~/.config/goa-1.0/accounts.conf .

I created an upstream bug in the hopes that somebody will actually see it: https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/32

I get that it's annoying when users think their bug is the most important one and needs to be fixed immediately - 
but you have to realize that there is no real workaround, because one can't even disable gnome-online-accounts, because something[1] and the bugs requesting it get closed with "NOTABUG". 

Honestly wondering why nobody cares.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1379070#c11

--- Additional comment from Alexander Korsunsky on 2019-02-27 13:36:04 UTC ---

I was using the KCM kerberos ticket cache provided by the package sssd-kcm.

Another workaround suggested by @debarshir [1] that doesn't involve killing gnome-online-accounts is to switch back to the KEYRING ticket cache by removing the sssd-kcm package.

This is working for me.

[1] https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/32#note_419973

--- Additional comment from Albert Szostkiewicz on 2019-04-08 01:54:40 UTC ---

Same issue here, getting millions of messages:

 goa-daemon[2562]: goa_provider_get_for_provider_type: assertion 'provider_type != NULL' failed
 goa-daemon[2562]: Unsupported account type (null) for identity (null) (no provider)
Comment 2 Debarshi Ray 2020-03-06 16:50:34 UTC 
*** Bug 1724521 has been marked as a duplicate of this bug. ***
Comment 3 Debarshi Ray 2020-03-06 17:29:20 UTC 
Do you still see this problem? I am asking because on many of the other reports about the same bug, people have been saying that they saw this issue go away over time.

If you are still seeing this, then I need some more information because while it seems to constantly affect some users, it just doesn't reproduce for others.

If you start from a clean state (ie., no Kerberos tickets or accounts anywhere) then what are the exact steps to trigger this?

To attain a clean state:

* Hard disable /usr/libexec/goa-daemon and /usr/libexec/goa-identity-service by removing the executable bit and killing them, so that they don't start up again.

* Remove all stanzas with "IsTemporary=true" or "Provider=kerberos". Or even better, just remove that file.

* Reboot the machine just to reset all the SSSD daemons, which offer the Kerberos KCM caches.

* Restore the executable bit on /usr/libexec/goa-daemon and /usr/libexec/goa-identity-service.

At this point, what are the exact steps that cause this bug to appear? For example, are you creating your Kerberos tickets using kinit? Or are you creating your tickets using the Online Accounts GUI in Settings? If you are using the GUI, then do you select the checkbox to save your password? Do you add more than one Kerberos account? Or just one?

I suspect that kinit was used, not the GUI. If so, when does this behaviour show up? Does one have to wait for the ticket to expire?

Also, does your Kerberos Key Distribution Centre (or KDC) allow tickets to be renewed or not?
Comment 4 Brandon Clark 2020-04-08 22:50:21 UTC 
The customer that the listing was opened for mentioned that the issue is still occurring, albeit infrequently. As such, they are unable to determine steps for reproducing until their production outage in May.

However, they have confirmed that they're using MS AD which does renew the tickets.
Comment 5 Debarshi Ray 2020-05-29 15:54:55 UTC 
(In reply to Brandon Clark from comment #4)
> The customer that the listing was opened for mentioned that the issue is
> still occurring, albeit infrequently. As such, they are unable to determine
> steps for reproducing until their production outage in May.
> 
> However, they have confirmed that they're using MS AD which does renew the
> tickets.

Ok, that's good to know.

> * Remove all stanzas with "IsTemporary=true" or "Provider=kerberos". Or
> even better, just remove that file.

By "that file", I mean ~/.config/goa-1.0/accounts.conf

Setting NEEDINFO while we wait for further details.
Comment 6 Tomas Popela 2020-08-27 14:42:22 UTC 
Closing the bug as the attached customer case is closed.
Note You need to log in before you can comment on or make changes to this bug.