[Patch] Auto-Close dbus-daemon when unused

[Leon Winter]

Hi,

thanks for all your input.

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

Sadly we do use terminal-multiplexers like screen(1) and such. The working
assumption normally is that all processes are running for a reason. They might
be in use or holding a detached shell. Users may very well have processes
running accross "sessions" (like X11 sessions). Also we are not running systemd
at this time.

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

We are indeed using the old package.

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

Currently we are using autolaunching without the "--exit-with-session" feature
and it works as advertised.

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

The mentioned race condition can indeed be fixed in the implementation and does
not pose a problem in principal.

> 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).

I am not too familiar with DBus but I does seem that such a service activation
is indeed currently not properly handled.

> This is going to break horribly if there are user-visible applications
> that happen to have been started via service-activation, [...]

Since we have not encountered any problems with the applications you named, it
seems, we are not using service-activation but are rather starting applications
manually passing information to it via arguments and the environment.

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

I am not sure why you would call inherited process attributes random. We tend to
launch applications (like evince) with specific environment variables (like
PRINTER). We would then like evince to use the given printer.
If I understand service-activation correctly, services are forked from the DBus
daemon. So to achieve the same result with service activation, one would either
need to update the environment of services started from dbus with
dbus-update-activation-environment(1) and then quickly launch evince (sounds
racy) or hopes that evince offers a DBus API to change printers and use that.
Since PRINTER is a pretty standardized way of setting a printer one would hope
that the "change printer" interface in DBus (should it exist) would also be
implemented by all such applications.

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

Indeed, currently every manually started applications are considered clients.
Why would one start a service manually when it can be started on demand?

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

My requirements are indeed unusual as we are running a high uptime multi-user
system and would like the keep the process list short. I would of course be very
happy if patching would not be required and the problems could solved another
way.

Of the two issues of

(a) lingering dbus-daemons after user sessions and
(b) limiting the runtime of dbus-daemon to the time of actual usage

we can consider (a) fixed when having DBus tied to X11 by using
"--exit-with-session" for such "user session = X11 session" scenarios.
Luckily most dbus-dependent applications require X11 anyway so it not much of an
ask for DBus to require X11 as well. However running non-X11 DBus-dependent
applications via SSH connections would then not be possible. I am currently not
aware that we would have such non-X11 DBus-dependent applications running.

The issue (b) is partly addressed when using "autolaunching". Should no
application require dbus, no dbus-daemon process is running. Yet when a single
application autolaunch dbus it will stick around until the session ends despite
nobody ever requires DBus any more (other then the application that spawned it
in the first place). Sure, the dbus-daemon will be terminated once the user logs
out, but *until* then it stays alive without purpose wasting resources.
Following the terminology of "autolaunch", the feature I am proposing is
"autoexit" very orthogonal in functionality but refering to the time span
*after* dbus use instead of *before* dbus use.

Normal situation (dbus-launch --exit-with-session Xsession):

                    dbus-daemon runtime
        |---------------------------------------------|
  session start                                  session end

Autolaunch situation:

                        evince
                      o---------o 
                               dbus-daemon runtime
        |              o------------------------------|
  session start        ^                          session end
                 dbus autolaunch

Situation with newly proposed "auto-exit":

                        evince
                      o---------o 
                        dbus-daemon runtime
        |              o-------------------o          |
  session start        ^                          session end
                 dbus autolaunch

                                 \---------/
                                time out span

Best regards,
Leon