GNOME Bugzilla – Bug 764029
goa-daemon (and most other D-Bus services) not stopped when the user session goes away
Last modified: 2021-06-14 18:23:18 UTC
Created attachment 324540 [details]
Credentials have expired
I have deleted the accounts, re-created them, logged in, logged out, and nothing I do seems to enable the accounts.
I have set up 1 Google account, the Google Drive for that account appeared but I cannot access it. When I use gnome-online-account it always states "Credentials have expired. Sign in to enable this account".
I have signed in many times, very carefully.
Further to this, if I delete the account from g-o-a and enter it in Evolution, it works fine.
I have the same issue in Fedora 25. Google account just shows "Credentials have expired" message. Re-creation of the account does not help. Really annoying issue.
I saw many reports and complains on the web.
Related bug for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1350678
This may be a better description of the bug in Fedora, as the symptoms are basically similar:
Logging out creates two problems with GOA:
1. Evolution throws an error about credentials being unavailable (doesn't matter for me if it's my Google account or a Microsoft Exchange account, both have problems)
2. Trying to delete the accounts throws an error in GOA about credentials (but they are deleted from GOA).
The problem is fixed as a workaround by restarting the OS and adding the accounts again in GOA.
However, the problem reappears if I log out.
*** Bug 769196 has been marked as a duplicate of this bug. ***
(In reply to james73 from comment #3)
> The problem is fixed as a workaround by restarting the OS and adding the
> accounts again in GOA.
You don't need to delete or re-add the accounts. Just a reboot is enough.
*** Bug 756414 has been marked as a duplicate of this bug. ***
*** Bug 773679 has been marked as a duplicate of this bug. ***
I find just killing goa-daemon after logging back in is enough.
Still annoying though. :-/
*** Bug 777674 has been marked as a duplicate of this bug. ***
*** Bug 769575 has been marked as a duplicate of this bug. ***
Could be related to #780338 as well?
*** Bug 780338 has been marked as a duplicate of this bug. ***
*** Bug 781564 has been marked as a duplicate of this bug. ***
I realize that I have never written at length about the cause of this bug, other than some cryptic comments on the downstream Fedora bug  and some conversations with halfline scattered across IRC and e-mail.
So, for those who are following along ...
This is a case of goa-daemon not being able to talk to gnome-keyring-daemon once the user logs out/in without a reboot. It happens when the D-Bus session is set up by systemd --user to be shared across all login sessions, as opposed to being tied to a graphical login session. Fedora >= 24 and Ubuntu >= 16.10 are some of the distributions that use systemd --user.
I'd suggest reading this for some background on D-Bus sessions, user sessions and login sessions:
In short, earlier everybody was using a separate D-Bus session per each graphical login session. Non-graphical sessions started via ttys, ssh, etc. can be ignored because they usually didn't launch a D-Bus session. Every graphical login would get its separate copy of all D-Bus daemons, including gnome-keyring-daemon and goa-daemon, and they'd die with the D-Bus session when the user logged out.
One problem with this set-up (as noted in the above URL) is that you cannot use D-Bus services from screen(1) started from a graphical login session. The moment the user logs out the D-Bus session will be over and whatever was left running under screen(1) won't be able to use D-Bus anymore.
With systemd --user, the D-Bus session may survive across multiple login sessions, and the distinction between graphical and non-graphical sessions is blurred. Hence programs launched from a ssh login share the D-Bus session with a graphical login, and the D-Bus session ends only when the user's last login is terminated.
This shouldn't have been a problem because both goa-daemon and gnome-keyring (and every other D-Bus service) would continue to be tied to one D-Bus session and have the same lifetime. They would both die when the user D-Bus session dies and reappear on the same shared bus when needed again.
Except for two things.
Systemd has a per-user flag called KillUserProcesses. It determines if systemd will terminate all left-over user processes once all the login sessions are gone. If it does that, then things like screen(1) break (unless work is done to explicitly avert that). If it doesn't, then all the user D-Bus services are left running even if nobody is using them.
So far Fedoras  24 and 25 set it to "no" (maybe Ubuntu does the same?). This means that screen(1) kept working but the D-Bus services didn't get cleaned up. There is a plan  to fix that in Fedora 26 which requires doing extra work to prevent screen(1) from breaking.
The second problem is that gnome-keyring-daemon is tied to PAM. This is where my understanding becomes foggy. It has a PAM module that decrypts the keyring during login, and it remains tied to the login session (not the user session) even with systemd --user.
Therefore, when the user logs back in, she gets the goa-daemon from her previous login but a new gnome-keyring-daemon. Any gnome-keyring D-Bus calls made by the old goa-daemon fail, giving the impression that all the accounts are expired.
Yes, Debian and Ubuntu compile systemd using --without-kill-user-processes
The real underlying cause of why goa-daemon can't talk to the new gnome-keyring is bug 765406, which was reported against libsecret a year ago and never fixed.
Once libsecret is fixed (and it should be), goa-daemon can simply pick up the new gnome-keyring at the next login, with no further changes anywhere in the stack. gnome-keyring can also crash on its own, and goa-daemon should not be hosed by that.
(In reply to Giovanni Campagna from comment #16)
> The real underlying cause of why goa-daemon can't talk to the new
> gnome-keyring is bug 765406, which was reported against libsecret a year ago
> and never fixed.
Thanks for the pointer, Giovanni. I didn't know about that one. I'll take a look and hopefully it will give me an idea about gnome-keyring and libsecret internals.
Michael pointed out bug 768943. However, it is not immediately clear to me what it is about. 'ps aux | grep gnome-keyring-daemon' says that I always get a new gnome-keyring-daemon process after restarting the session.
(In reply to Giovanni Campagna from comment #16)
> gnome-keyring can also crash on its own, and goa-daemon should
> not be hosed by that.
Yes, I have seen the occasional bug report (even before systemd --user was a thing) where g-o-a is unable to use gnome-keyring. I never got around to digging into libsecret / gnome-keyring, so this might be it.
*** Bug 772768 has been marked as a duplicate of this bug. ***
Created attachment 354200 [details] [review]
manager: add bus daemon dbus api xml file
Created attachment 354201 [details] [review]
system: add api for detecting if this is the last session for a user
Created attachment 354202 [details] [review]
manager: kill off bus clients at log out
I'm going to push the above into gnome-session as a stop gap until we get the lifecycle problems worked out in the individual services.
Attachment 354200 [details] pushed as 1e3b5a2 - manager: add bus daemon dbus api xml file
Attachment 354201 [details] pushed as f708bbb - system: add api for detecting if this is the last session for a user
Attachment 354202 [details] pushed as e7a650b - manager: kill off bus clients at log out
Jeremy backported those changes to Ubuntu and they seem to create issues, with the patches gnome-session version it's not possible to log into GNOME again after a logout (entering the password on the login manager opens the session and it closes before displaying anything, syslog errors suggests clients are failing to use dbus for some reason)
Let's reassign this bug to gnome-session. goa-daemon not being stopped is a general session lifecycle issue and the patches here try to address that part.
As for the libsecret / gnome-keyring breakage (comment 16, bug 765406), we are either going to fix libsecret or workaround the problem in gnome-online-accounts. If it is the latter, then we can repurpose some other bug for it. I have seen a few "strange" bugs over the years where libsecret couldn't use gnome-keyring for no apparent reason.
I am playing with it a bit in gnome-online-accounts:wip/rishi/libsecret-workaround. I will keep you updated.
I filed bug 784944 against gnome-online-accounts to workaround the libsecret problem (bug bug 765406).
so attachment 354202 [details] [review] has a big problem. it ends up killing off the systemd --user instance since that, itself, is a bus client ... See below conversation:
<whot> is there anything in gdm that may kill the systemd user session on log out?
<whot> I have a weird issue on my F26 box where if I log in and out of a session, everything is fine. If I ssh into the machine and leave the ssh connection open, then use the local keyboard to log in/out of a session I lose the systemd user service
<whot> systemctl restart firstname.lastname@example.org brings it back, but I just can't figure out why it dies
<whot> this seems to be related to gdm, it doesn't happen with startx and I can happily log in/out of a tty while an ssh connection is active without the user service going down
<whot> any hints on what to do or how to figure out what's going on would be appreciated
<halfline> well one thing we have that's sort of related, but doesn't quite explain it
<halfline> is if it's the last graphical session, we kill all bus clients
<halfline> i wonder if the systemd instance is a bus client
<halfline> you know it probably is
<halfline> i guess that would explain it
<halfline> yup d-feet confirms it is
I think, as far as workarounds go, we should maybe revert this and instead just manually restart dbus.service, that way services that intentionally outlive the dbus session lifetime don't get summarily killed.
Created attachment 355955 [details] [review]
Revert "manager: kill off bus clients at log out"
This reverts commit e7a650b88b92c3381eccef7bf4765fa814389aaa.
Created attachment 355956 [details] [review]
Revert "manager: add bus daemon dbus api xml file"
This reverts commit 1e3b5a2f4c6cb65dfa94b65a84d1f6c2c9dd61fe.
Created attachment 355957 [details] [review]
manager: restart user bus if last graphical session
There are desktop services (such as goa-daemon, e-d-s, etc)
that don't open the display, but rely on dbus-daemon to scope
the session. These days dbus-daemon is a user bus, not a sesssion,
bus which leaves these services alive after log out.
This commit checks to see if we're the last desktop session for the
user at log out time, and if so, restarts the dbus daemon. This
will lead to existing clients getting booted and die, but allow user
bus clients that want to outlive a session to stick around if they so
Longer term, clients should stop relying on the session bus to define
Review of attachment 355957 [details] [review]:
@@ +956,3 @@
so in the common case, the daemon is going to get shutdown like a second after its restarted since we're logging out (which isn't optimal).
It's socket activated though, so I think we might able to get away with just stopping it instead of restarting it!
Attachment 355955 [details] pushed as 0f1adb1 - Revert "manager: kill off bus clients at log out"
Attachment 355956 [details] pushed as 1dd8905 - Revert "manager: add bus daemon dbus api xml file"
Attachment 355957 [details] pushed as 97d1cf5 - manager: restart user bus if last graphical session
(decided to push as is for now, since i'm about to do the release and haven't tested the other approach yet)
Could we please also backport these to gnome-3-24 instead of carrying them downstream?
i didn't want to push attachment 354202 [details] [review] to stable since it addresses a user bus problem in a way that affects non-user-bus installations (so it's more appropriate for downstreams to pick up individually if they've switched to user bus). attachment 355957 [details] [review] shouldn't affect non-user-bus situations so i'd be more comfortable pushing it to stable. but let's let it sit on the unstable branch for a bit to make sure there isn't more fall out first.
Is it time to close this?
- improved systemd error handling
- gnome-session-inhibit fix
- Make sure non-graphical services get
killed at log out when there's
-> Does this mean this is fixed in 3.24 finally or any other patch needs to be applied downstream? Thanks
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).
If you can still reproduce the situation described in this ticket in a recent
and supported software version of gnome-session, then please follow
and create a new ticket at
Thank you for your understanding and your help.