After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 764029 - goa-daemon (and most other D-Bus services) not stopped when the user session goes away
goa-daemon (and most other D-Bus services) not stopped when the user session ...
Status: RESOLVED OBSOLETE
Product: gnome-session
Classification: Core
Component: general
3.20.x
Other Linux
: Normal critical
: ---
Assigned To: Session Maintainers
Session Maintainers
: 756414 769196 769575 772768 773679 777674 780338 781564 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-03-22 13:53 UTC by Jason Etherton
Modified: 2021-06-14 18:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Credentials have expired (80.76 KB, image/png)
2016-03-22 13:53 UTC, Jason Etherton
  Details
manager: add bus daemon dbus api xml file (6.59 KB, patch)
2017-06-21 20:08 UTC, Ray Strode [halfline]
committed Details | Review
system: add api for detecting if this is the last session for a user (14.85 KB, patch)
2017-06-21 20:08 UTC, Ray Strode [halfline]
committed Details | Review
manager: kill off bus clients at log out (12.91 KB, patch)
2017-06-21 20:08 UTC, Ray Strode [halfline]
committed Details | Review
Revert "manager: kill off bus clients at log out" (12.98 KB, patch)
2017-07-19 15:07 UTC, Ray Strode [halfline]
committed Details | Review
Revert "manager: add bus daemon dbus api xml file" (6.66 KB, patch)
2017-07-19 15:07 UTC, Ray Strode [halfline]
committed Details | Review
manager: restart user bus if last graphical session (4.73 KB, patch)
2017-07-19 15:07 UTC, Ray Strode [halfline]
committed Details | Review

Description Jason Etherton 2016-03-22 13:53:01 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.
Comment 1 Jason Etherton 2016-03-22 16:26:36 UTC
Further to this, if I delete the account from g-o-a and enter it in Evolution, it works fine.
Comment 2 Zdenek 2016-11-17 01:37:21 UTC
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

gnome-online-accounts-3.22.1-1.fc25.x86_64
Comment 3 james73 2016-12-28 07:17:49 UTC
This may be a better description of the bug in Fedora, as the symptoms are basically similar:

https://bugzilla.redhat.com/show_bug.cgi?id=1340203

To summarise:
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.
Comment 4 Debarshi Ray 2017-01-06 16:27:20 UTC
*** Bug 769196 has been marked as a duplicate of this bug. ***
Comment 5 Debarshi Ray 2017-01-06 16:30:43 UTC
(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.
Comment 6 Debarshi Ray 2017-01-06 18:28:35 UTC
*** Bug 756414 has been marked as a duplicate of this bug. ***
Comment 7 Debarshi Ray 2017-01-06 18:37:18 UTC
*** Bug 773679 has been marked as a duplicate of this bug. ***
Comment 8 Brian J. Murrell 2017-01-06 21:14:42 UTC
I find just killing goa-daemon after logging back in is enough.

Still annoying though.  :-/
Comment 9 Debarshi Ray 2017-01-24 09:29:20 UTC
*** Bug 777674 has been marked as a duplicate of this bug. ***
Comment 10 Debarshi Ray 2017-04-09 11:20:59 UTC
*** Bug 769575 has been marked as a duplicate of this bug. ***
Comment 11 Behrooz Nobakht 2017-04-20 10:45:19 UTC
Could be related to #780338 as well?
Comment 12 Debarshi Ray 2017-04-21 08:35:58 UTC
*** Bug 780338 has been marked as a duplicate of this bug. ***
Comment 13 Debarshi Ray 2017-04-21 08:47:06 UTC
*** Bug 781564 has been marked as a duplicate of this bug. ***
Comment 14 Debarshi Ray 2017-04-21 11:34:04 UTC
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 [1] 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:
https://lists.freedesktop.org/archives/dbus/2015-January/016522.html

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 [2] 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 [2] 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.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1340203
[2] https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_default
Comment 15 Jeremy Bicha 2017-04-21 11:38:16 UTC
Yes, Debian and Ubuntu compile systemd using --without-kill-user-processes
Comment 16 Giovanni Campagna 2017-05-24 16:41:13 UTC
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.
Comment 17 Debarshi Ray 2017-05-25 16:00:38 UTC
(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.
Comment 18 Debarshi Ray 2017-05-25 16:08:12 UTC
(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.
Comment 19 Debarshi Ray 2017-06-07 16:46:02 UTC
*** Bug 772768 has been marked as a duplicate of this bug. ***
Comment 20 Ray Strode [halfline] 2017-06-21 20:08:27 UTC
Created attachment 354200 [details] [review]
manager: add bus daemon dbus api xml file
Comment 21 Ray Strode [halfline] 2017-06-21 20:08:33 UTC
Created attachment 354201 [details] [review]
system: add api for detecting if this is the last session for a user
Comment 22 Ray Strode [halfline] 2017-06-21 20:08:39 UTC
Created attachment 354202 [details] [review]
manager: kill off bus clients at log out
Comment 23 Ray Strode [halfline] 2017-06-21 20:09:24 UTC
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.
Comment 24 Ray Strode [halfline] 2017-06-21 20:33:22 UTC
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
Comment 25 Sebastien Bacher 2017-07-07 10:17:40 UTC
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)
Comment 26 Debarshi Ray 2017-07-11 05:54:58 UTC
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.
Comment 27 Debarshi Ray 2017-07-14 10:22:44 UTC
I filed bug 784944 against gnome-online-accounts to workaround the libsecret problem (bug bug 765406).
Comment 28 Ray Strode [halfline] 2017-07-19 14:21:52 UTC
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 user@13349.service 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.
Comment 29 Ray Strode [halfline] 2017-07-19 15:07:34 UTC
Created attachment 355955 [details] [review]
Revert "manager: kill off bus clients at log out"

This reverts commit e7a650b88b92c3381eccef7bf4765fa814389aaa.
Comment 30 Ray Strode [halfline] 2017-07-19 15:07:40 UTC
Created attachment 355956 [details] [review]
Revert "manager: add bus daemon dbus api xml file"

This reverts commit 1e3b5a2f4c6cb65dfa94b65a84d1f6c2c9dd61fe.
Comment 31 Ray Strode [halfline] 2017-07-19 15:07:48 UTC
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
desire.

Longer term, clients should stop relying on the session bus to define
their lifetime.
Comment 32 Ray Strode [halfline] 2017-07-19 15:16:15 UTC
Review of attachment 355957 [details] [review]:

::: gnome-session/gsm-manager.c
@@ +956,3 @@
+                                             "/org/freedesktop/systemd1",
+                                             "org.freedesktop.systemd1.Manager",
+                                             "TryRestartUnit",

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!
Comment 33 Ray Strode [halfline] 2017-07-19 16:45:31 UTC
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
Comment 34 Ray Strode [halfline] 2017-07-19 16:47:01 UTC
(decided to push as is for now, since i'm about to do the release and haven't tested the other approach yet)
Comment 35 Michael Catanzaro 2017-07-19 18:31:41 UTC
Could we please also backport these to gnome-3-24 instead of carrying them downstream?
Comment 36 Ray Strode [halfline] 2017-07-20 13:51:42 UTC
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.
Comment 37 Debarshi Ray 2017-10-22 19:25:51 UTC
Is it time to close this?
Comment 38 Pacho Ramos 2017-12-22 11:07:09 UTC
===============
Version 3.24.2
===============
	- improved systemd error handling
	- gnome-session-inhibit fix
	- Make sure non-graphical services get
	  killed at log out when there's
	  systemd --user.

-> Does this mean this is fixed in 3.24 finally or any other patch needs to be applied downstream? Thanks
Comment 39 André Klapper 2021-06-14 18:23:18 UTC
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
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-session/-/issues/

Thank you for your understanding and your help.