Starting the kdbus discussions

[Simon McVittie]

On 02/01/14 09:38, Alberto Mardegan wrote:
> I have only one major concern, which is about the activation of the
> kdbus services. From what I understood while reading this thread,
> activatable services should ship a systemd unit file (or two?).

Services wishing to be activatable via "traditional D-Bus" must ship a
traditional D-Bus .service file.

Services wishing to be activatable via systemd must ship a systemd unit,
somewhat confusingly also named *.service (but in a different directory).

Services wishing to be activatable in both ways must ship both, with the
D-Bus file containing a reference to the systemd file.

AIUI, the only thing that kdbus+systemd changes is that kdbus cannot do
traditional D-Bus activation at all, and requires a separate user-space
activation helper. The only implementation of that so far is in systemd,
which means services wishing to be activatable on kdbus+systemd systems
MUST ship a systemd unit, and MAY also continue to ship a traditional
D-Bus .service file.

I believe it would be entirely possible to implement a user-space
activation helper that used the "traditional D-Bus" activation scheme
instead of systemd's. In fact, I've sometimes considered replacing
dbus-daemon-launch-helper with a privileged daemon that implements
something remarkably similar to systemd's "activator" protocol, but done
in terms of "traditional D-Bus" .service files, so that we can have one
less setuid binary.

(For the record, the reason I didn't do this is that that would require
trusting a larger chunk of libdbus code for use in a highly privileged
process - but then again, systemd did this until it moved to the
libsystemd-bus reimplementation, gdm did this until it moved to GDBus,
and AIUI Upstart still does that, so perhaps that isn't a cause for
concern.)

> Would it
> be possible to make this feature independent of systemd?
> That is, ship a .service file (similar to the old D-Bus service files)
> in some place such as /usr/share/kdbus/services/, and any
> systemd-specific data elsewhere (or even in the same file, but maybe
> with a "X-systemd-" prefix)?

http://xkcd.com/927/

If you're considering implementing an alternative non-systemd userland
for kdbus, why not continue to use the traditional D-Bus .service files
in their traditional location, perhaps with additional info in a
[Foobar] section (where Foobar is the name of the alternative userland
component)? I don't see any reason to invent a third directory tree.

The only reason to use a third directory tree or file format would be if
Foobar was integrated into something that already has its own directory
tree (such as Upstart), in which it might make sense to use the
format/location defined by that "something" (e.g. Upstart jobs in
/etc/init) in the same way that activation via systemd uses systemd units.

    S