[Patch] Auto-Close dbus-daemon when unused

[Leon Winter]

Hi,

> If that's your reasoning, then doesn't it apply equally to D-Bus
> services, and to processes that merely *use* D-Bus?

Processes that use D-Bus are fine. Normal GUI applications quit when X11 is
terminating so the dbus-daemon notices the disconnects of "clients" and could
then also terminate. If a non-GUI processes would rely on D-Bus than it is
perfectly fine for the dbus-daemon stay alive along with it even if the X11 is
killed. If the running process was left there by mistake, it is a user mistake.
The corresponding dbus-daemon would not be a fault then as it merely served the
mistakenly running process.

> Processes that use D-Bus are normally expected to exit when the
> dbus-daemon does, because of exactly your situation: system
> administrators on massively-shared systems hated it when pre-D-Bus
> daemons like gconf persisted after a session was over. However, you
> can't have it both ways - there has to be some rule for deciding whether
> a process is allowed to persist.

For GUI applications this questions is answered as they die when X11 is killed.
The other processes can stay. In a patched D-Bus world, dbus-daemon would
terminate shortly after due to its inactivity (as D-Bus dependent process are
usually X11 ones).

> If there is some more complex rule for deciding case-by-case whether
> terminating a background process is desired or not, then I suggest using
> it as input for systemd-logind. I believe the systemd maintainers' plan
> is that eventually, tools like screen will register themselves as a
> session, so that a user's dbus-daemon etc. stay running as long as they
> have at least one X11, screen or tty session.

Such a whitelist/blacklist approach seems complicated and error-prone imho.
Should D-Bus become the requirement for non-X11 applications like screen and
tmux, the auto-exit logic would still be correct but maybe never executed.
At least for us, currently the dependency on D-Bus is not severe so auto-exit
would make sense for us.

> I would recommend doing so. systemd-logind is the most consistent model
> of "what it means to be in a session" that I've encountered, and
> dbus-user-session makes a lot of sense (at least, it does to me).

I am sure it makes sense in a lot of use cases I suspect not in ours as we are
really not using D-Bus as much as "everyone else".

> > The mentioned race condition can indeed be fixed in the implementation and does
> > not pose a problem in principal.
> 
> That's easy for you to say, you won't be the one responsible for
> maintaining it in 5 years' time :-)

Ironically I have originally written the patch 4 years ago and ported it to
newer versions since. My intention was to make it a little bit easier for me to
add such functionality accross new versions. Ideally would be to have the
feature upstream which was extremely unlikely right from the start. However as I
suggested originally it might be possible to go with Option 2: Move data
structures into header files instead of C files. This would not really change
anything for you, but would reduce my patching effort greatly.

> Environment variables are actually not the main thing I'm worried about.
> I'm more concerned about the more obscure corners of process attributes,
> such as rlimits, setuid/setgid, process groups, whether or not SIGPIPE
> is blocked, etc. - many of which make sense in a CLI environment, but
> are just a source of failures for GUI components and services.

Okay, it is nice of you to provide such a "clean state" for GUI processes to
launch from when invoked via service action. Technically if the launch is only
possible in that way, either the calling application or the launched GUI
application has a bug. In that case, we are happy to find and fix the bug
instead of working around it by providing said "clean state".

> The central problem with environment variables for this sort of thing
> is: suppose you already had an evince process running with PRINTER=hp,
> and now you start another /usr/bin/evince (which communicates with the
> existing process to make that process do the actual work) with
> PRINTER=canon. Which printer will each window end up using? The answer
> is that it depends whether the single-instance mechanism gathers up
> (some subset of) the environment of the process-starter and passes it
> across D-Bus to the existing instance to be associated with the new window.

One can only hope that the author of single-instance applications consider this
(which they probably did not). When not employing single-instance semantics it
would be crystal clear what the final result would be.

> The existing instance cannot just putenv("PRINTER"), because that's
> [...]
> G_APPLICATION_SEND_ENVIRONMENT in GApplication.

This sounds like a viable solution but is requires a lot of effort in comparison
to forkexec (when discarding the "clean state" argument).

> I'm aware that setting environment variables is a configuration
> mechanism that has been around for decades and is somewhat
> well-understood, but that doesn't necessarily mean it provides a good
> user-experience.

It surely requires less effort for both the programmer and the user. The user
just prepends PRINTER=canon and has the printer set. Meanwhile the programmer
does not has to worry about incoming API calls and setting serialized
environments sent via socket but can always rely on the environment it was
launched from. If user experience refers to "speed" the service activation could
of course indeed be faster when an already running process is just getting
"focused" again.

> Any form of autolaunching for background processes is particularly
> problematic if you're making active use of changing environment
> variables during a session, because the new dbus-daemon (or whatever)
> will have whatever arbitrary environment happens to have been active
> when it was autolaunched, which it then passes on to its children.

If the dbus-daemon is so worried about the environment it could just clear it.
>From my understanding you currently assure an empty clean state by starting
early (like before/at xsession time) and not being "randomly" forkexec() when
autolaunching. At least for the environment you can garantuee the same thing
when clear it before launching (like "env -i").

> (For example, if I'm logged in from a thin client in a particular
> location, it would make sense for there to be a way for me or a sysadmin
> to arrange for my default printer to be set to one that is in that
> location - but don't confuse the policy, "give me a nearby printer",
> with the mechanism, "select a printer using environment variables".)

We do have such a mechanism in place which uses the X11 display name to identify
nearby printers. Once this discovery is done, it does not need to recomputed and
will be stored in the PRINTER environment variable. If one wants to override
this setting and manually select another printer one can simply set PRINTER to a
different value.

> This might also make auto-termination more feasible to implement: for
> instance, it might be possible for dbus-daemon to "give back" the socket
> to systemd in an atomic way, and be sure that it has handed over its
> responsibility and can safely exit.

In a systemd world you are probably right as it provides yet another maybe more
useful semantic of a "user session" (unlike auxiliary constructs like the X11
runtime).

> How does this resource use compare with the rest of the user's session?
> My guess is that the answer is "it isn't significant", although of
> course I could be wrong.

This depends on the system setup but for your normal use-case you are right
(especially when using DE like gnome/KDE). I would not suggest auto-exit is
useful for everyone but we would certainly appreciate it.

> If auto-terminating the dbus-daemon has sufficiently compelling
> resource-use advantages that it is worth the code complexity of
> implementing it, I'd want to see a design that explains how the race
> condition can be avoided, before reviewing any code.

I don't think I can persuade you that you would feel it was "suffiently
compelling" especially since this would not be true for the majority of users
(that don't care about resource/memory use in any way). Yet maybe mentioned
.h struct restructuring would not hurt too much upstream but enable greater
customization downstream. Currently any kind of book-keeping of connected
"clients" is difficult across data structures because they are opaque/private
(that is why currently the patch is so painful).

Regards,
Leon