if you run

$ systemctl --user disable dbus.socket
$ systemctl --user disable dbus.service

and reboot, does the problem go away?

I think last august or something like that, dbus changed to being a user bus.  My guess is it needs code to make it exit when the last session run by the user is put in the closing state (according to logind).

(In reply to Ray Strode [halfline] from comment #1)
> $ systemctl --user disable dbus.socket
> $ systemctl --user disable dbus.service

I don't think you can do that; if enabled at compile time (and the necessary files are installed), the user bus is statically enabled. You could mask those services instead of disabling them, though.

> I think last august or something like that, dbus changed to being a user
> bus.

Upstream, this is opt-in behaviour. Some distributions (Arch, Fedora) have enabled this unconditionally. In Debian, I set it up as a separate package (dbus-user-session_*.deb) which can be installed in addition to the normal dbus packages.

> My guess is it needs code to make it exit when the last session run by
> the user is put in the closing state (according to logind).

The user bus works alongside the `systemd --user` represented by user@1000.service (or whatever your numeric uid is, if not 1000). It should terminate if and only if the `systemd --user` does: I specifically don't want it to have its own special D-Bus life-cycle. If the hypothetical kdbus future ever happens, that isn't likely to have its own special life cycle either.

If you want user@1000.service to terminate with your last login session, enable KillUserProcesses=yes in /etc/logind.conf (see logind.conf(5)). Note that this will break screen(1) and similar tools, unless/until they are modified to register themselves as a systemd user-session in their own right.

I have replied in: https://bugs.freedesktop.org/show_bug.cgi?id=94508

Feel free to close this bug if preferred... the reason I keep it opened is that I am unsure if maybe the app (I don't know exactly witch one :S) that is launching the "offending" dbus-daemon at graphical login time should also take care of killing it at logout (in that case it would be a gnome-session bug probably)

(In reply to Simon McVittie from comment #2)
> (In reply to Ray Strode [halfline] from comment #1)
> > $ systemctl --user disable dbus.socket
> > $ systemctl --user disable dbus.service
> 
> I don't think you can do that; if enabled at compile time (and the necessary
> files are installed), the user bus is statically enabled. You could mask
> those services instead of disabling them, though.
really? That's surprising.  How does it achieve that?

> The user bus works alongside the `systemd --user` represented by
> user@1000.service (or whatever your numeric uid is, if not 1000). It should
> terminate if and only if the `systemd --user` does: I specifically don't
> want it to have its own special D-Bus life-cycle. If the hypothetical kdbus
> future ever happens, that isn't likely to have its own special life cycle
> either.
I totally understand that viewpoint, and it's valid, but a few thoughts:

1) I'm pretty sure kdbus is not a thing anymore.  The people working on it have switched to a different project ( https://github.com/bus1/bus1 ) that is something entirely different (different goals, different design) from dbus.

2) A lot of programs currently tie their life cycle to the bus, because the bus was specifically designated as the thing that scopes a session (until last year when we did session->user).  We should fix the programs, of course, to watch sessions come up and down on their own.

3) For instance, gnome-shell/gnome-session should be fixed to show a dialog on other seats with something like:

 User already logged in on another seat.

  [ Wait ]  [ Log out of other seat ]

if the user is currently logged into an active seat. 

4) And, likewise, programs should be fixed to go away when the last session is closing.  We should probably fix that in GApplication.

5) But, dbus-daemon is one of those programs, too!  And fixing it will help with the straggling other programs that haven't been fixed yet.

6) The logind option is okay, and maybe it should be toggled by default, but it shouldn't be an "unbreak me" option where things fail to work properly unless it's switched.  

7) Also, as you mentioned, the option has certain, potentially controversial, side effects.  Doesn't mean we shouldn't toggle it by default, but it does mean it's not a no brainer to toggle it by default. Anyway, the toggling should happen in upstream systemd, not downstream.

https://github.com/systemd/systemd/pull/3005:
- enable KillUserProcesses by default
- elucidate the relationship between KillUserProcesses and lingering

We were following this one with a slightly different approach:
https://github.com/systemd/systemd/issues/2900

(In reply to Pacho Ramos from comment #3)
> I am unsure if maybe the app (I don't know exactly witch one :S) that
> is launching the "offending" dbus-daemon at graphical login time

`systemd --user`

> should also take care of killing it at logout

It does, or at least, it's meant to. I believe its definition of "logout" is that all processes belonging to your login session have exited.

If processes belonging to your login session remain running after the end of the login session was reported to logind via pam_systemd, then what `systemd --user` does is dependent on configuration:

* KillUserProcesses=yes: kill them, wait for them to die, continue to clean up user-services like dbus-daemon --session
* KillUserProcesses=no: wait (perhaps forever)

In the GNOME/gdm/gnome-session case, the end of the login session is (should be) reported via pam_systemd by gdm, after gnome-session terminates.

(In reply to Ray Strode [halfline] from comment #4)
> 1) I'm pretty sure kdbus is not a thing anymore.  The people working on it
> have switched to a different project ( https://github.com/bus1/bus1 ) that
> is something entirely different (different goals, different design) from
> dbus.

*shrug* I've lost track; please feel free to interpret "kdbus" as "any kernel-asssisted D-Bus-compatible message bus" (AF_BUS, AF_DBUS, kdbus, anything else that comes along).

I'm going to just continue to do what I have been doing, which is to try to make D-Bus a good implementation of its original goals, and urge the developers of message buses that claim to be compatible with D-Bus to make them *actually* compatible with D-Bus. If "bus1" doesn't claim to be compatible with D-Bus (doesn't use the same socket, etc.), then I don't need to worry about that: traditional D-Bus can coexist with it.

> We should fix the programs, of
> course, to watch sessions come up and down on their own.

If necessary, but if the lifetime tracking of login sessions vs. user-sessions is done correctly, then we shouldn't need to.

(In reply to Simon McVittie from comment #7)
> I'm going to just continue to do what I have been doing, which is to try to
> make D-Bus a good implementation of its original goals, and urge the
> developers of message buses that claim to be compatible with D-Bus to make
> them *actually* compatible with D-Bus.
Yea, as I understand it (could be wrong), there's not going to be a d-bus compatible kernel message bus.
 
> If necessary, but if the lifetime tracking of login sessions vs.
> user-sessions is done correctly, then we shouldn't need to.
what do you mean ?

(In reply to Ray Strode [halfline] from comment #8)
> > If necessary, but if the lifetime tracking of login sessions vs.
> > user-sessions is done correctly, then we shouldn't need to.
>
> what do you mean ?

I think what's happening here may be that a login-session is stuck in "closing" state (because processes within that login session haven't terminated), resulting in logind not closing the user-session. If logind does close the user-session, I believe that's meant to terminate the systemd --user instance gracefully, at which point dbus-daemon, gvfs, etc. will all get cleaned up the way the bug submitter expected. If KillUserProcesses addresses the reported symptoms, which it seems to do, then that's evidence in favour of that interpretation.

If lingering login-session processes such as screen(1) can't be avoided (for instance by making them register themselves as pseudo-login-sessions in their own right), my suggestion on systemd bug 2900 was to introduce a target that can be conflicted with to make systemd --user close services that have declared themselves as wanting to be closed when all of the remaining login-sessions are in a state no better than "closing". Having systemd --user (which is after all a service manager) reap these processes seems better than having all of them individually take responsibility for watching logind state and shutting themselves down.

(I don't experience this bug myself, so I could be wrong about what is happening.)

(In reply to Simon McVittie from comment #9)
> I think what's happening here may be that a login-session is stuck in
> "closing" state (because processes within that login session haven't
> terminated), resulting in logind not closing the user-session. If logind
> does close the user-session, I believe that's meant to terminate the systemd
> --user instance gracefully, at which point dbus-daemon, gvfs, etc. will all
> get cleaned up the way the bug submitter expected.
Yup, that's my understanding too.

> If KillUserProcesses
> addresses the reported symptoms, which it seems to do, then that's evidence
> in favour of that interpretation.
Sure, if we can flip KillUserProcesses then it fixes it for users by default.  It doesn't fix it for users who change the default though.

Maybe it's good enough, but it's weird to have an option that breaks things.

Anyway, looks like there's forward motion in the github links so lets close this out.

(In reply to Simon McVittie from comment #9)
> If KillUserProcesses
> addresses the reported symptoms, which it seems to do, then that's evidence
> in favour of that interpretation.
> 

KillUserProcesses addreeses the symptoms (well... with the known "issue" of absolutely all processes being killed and, hence, behaving a bit differently than dbus without user-session that allows to not rely on it)