[Patch] Auto-Close dbus-daemon when unused

[Simon McVittie]

On 24/09/15 10:58, Leon Winter wrote:
> we are running a Debian-based thin client setup with a central big machine and
> several lightweight clients. Since users run normal desktop applications like
> evince or firefox, dbus-daemons for their sessions are started. When they log
> out however, the dbus-daemons continue to linger around.

The normal way to get a dbus-daemon on Debian-based systems is currently
/etc/X11/Xsession.d/75dbus_dbus-launch. This uses "dbus-launch
--exit-with-session" during login. dbus-launch remains running, and when
it loses its connection to X11, during logout, it terminates the
"dbus-daemon --session" and itself.

The other traditional way to get a dbus-daemon is "autolaunching", which
launches a dbus-daemon on-demand when it is first used. Again, this uses
"dbus-launch --exit-with-session" to link the lifetime of the
dbus-daemon to the lifetime of the X11 session.

As a new feature in dbus 1.10, you can use systemd user sessions instead
(in Debian, this is the dbus-user-session package). This will "linger"
beyond the lifetime of a session if systemd lets it, because it could be
in use by non-GUI services; many other services will do the same. If you
don't want systemd to let this happen, use the KillUserProcesses
configuration option in /etc/systemd/logind.conf. This is the approach I
would recommend for a thin-client-style system, although you should note
that it (deliberately!) breaks the ability to leave background processes
running in something like screen(1) while logged out.

If you want D-Bus to be tied to the lifetime of an X11 session while
allowing non-D-Bus, non-GUI processes to "linger", remove the
dbus-user-session package and the system will go back to one of the old
ways of doing things.

If you are using one of these mechanisms but it isn't working correctly,
then that's a bug; instead of adding more complexity in an attempt to
work around it, please help us to fix it, by opening a bug on the
freedesktop.org Bugzilla. We'll need at least the information from the
standard bug-reporting template: steps to reproduce; what you expected
to happen; what actually happened. If you can reproduce it with one or
more Debian stable or testing virtual machines in a specified
configuration, that would be ideal.

> Thus for our setup we would like the
> dbus-daemon to automatically terminate when it is not actually used any more.

Having a process automatically terminate when it thinks it is no longer
in use is usually a bad idea, because there is a race condition: there
is some period of time between the process deciding it is going to die,
and the service (a listening socket in this case) actually going away.
If a client connects during that period, it will fail, and
auto-launching will not take place.

It is possible to mitigate this race with sufficiently clever code (some
sort of "commit/rollback" mechanism for the automatic shutdown), but
complexity is often the enemy of reliability, so my instinct is to look
for ways to not need it.

In addition, your implementation seems to work by counting the number of
connections to the bus that were not launched by service-activation
("clients" that are not "services" in your patch's terminology, although
that is not the way those terms are usually understood).

This is going to break horribly if there are user-visible applications
that happen to have been started via service-activation, which is a
direction that open source desktop environments are interested in,
particularly GNOME; that approach naturally provides "single instance"
semantics, and ensures that processes are started from a predictable
state rather than inheriting random process attributes from their
caller. For example, recent versions of Evince, gedit and GNOME Terminal
(GNOME's PDF viewer, text editor and terminal emulator respectively)
would not count towards holding the bus open.

Conversely, if a non-user-visible process has been started without going
via D-Bus service activation, for instance as a systemd user service,
then it *will* hold the bus open, even though I suspect this may not be
what you had intended to happen.

I suspect that systemd's KillUserProcesses=1 is a better approach to
reaping background processes on a application server for thin clients:
it is specifically designed to kill *all* of a user's background processes.

> At this point, I would like to ask if upstream would be willing to adapt such a
> (optional) behaviour.

I am reluctant to merge this feature, because your requirements are
unusual, and I suspect they can be achieved in a simpler way. I would
prefer to help you find that simpler way.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>