I am getting those messages on rhel8.2 as well:

1.run journalctl -f 
2.obtain kerberos tiket

Result:
journal is periodically spammed with 10+ messages:
Nov 20 14:16:24 t470s goa-daemon[6177]: Unsupported account type (null) for ID account_1565004688_4796 (no provider)
Nov 20 14:19:25 t470s goa-daemon[6177]: goa_provider_get_for_provider_type: assertion 'provider_type != NULL' failed

Pkgs:
gnome-online-accounts-3.28.2-1.el8.x86_64
sssd-krb5-2.2.0-19.el8.x86_64
krb5-libs-1.17-12.el8.x86_64
sssd-krb5-common-2.2.0-19.el8.x86_64
krb5-workstation-1.17-12.el8.x86_64


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


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)

any progress and/or solutions ?

--- Additional comment from Simone Caronni on 2019-10-15 04:19:39 UTC ---

Being hit by this on all our Fedora clients connected to FreeIPA, CPU constantly at 100% unless we remove sssd-kcm.

--- Additional comment from Ben Cotton on 2019-10-31 18:46:05 UTC ---

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.