[PATCH 0/5] Support service activation through Upstart

[Colin Walters]

On Sat, Dec 25, 2010 at 9:56 AM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
>
> Well, we thought about teaching systemd to read native D-Bus service
> files. However for a variety of reasons we decided not to do this. One
> thing is that it is kinda messy due to the location on disk, i.e. since
> it is currently on /usr, it is not possible to include it in the
> calculation of the initial transaction. Of course, we could fix this by
> declaring seperate /usr obsolete, or by moving all those files to
> /lib/dbus or so, but that's political work I am not keen to deal with,
> unless I really have to.

Sure, but a lot of system services also depend on /usr; and also if
the systemd unit file has the BusName, then you can skip having to
load the .desktop file.

> Also, it is definitely our intention to make people move to systemd
> .service files all across the board, and transparently supporting D-Bus
> .service files from within systemd wouldn't really help.

Well, it would be a benefit in that all activation would go through
systemd (and we could drop the setuid launch helper, a definite win).

> We also thought of getting rid of D-Bus service files entirely and
> replace them completely with systemd service files, but that is really
> hard since D-Bus reads all services files on boot-up and is able to
> offer a list of bus-activatable services to clients. systemd is
> optimized never to load unreferenced service files, so things are
> fundamentally incompatible here in regards to enumertion of
> services.

Sure, but ListNames is similar to "systemctl --all" in that it's
something for system administrators and debugging/developer tools.  If
anything in the OS is calling ListNames during bootup e.g. I'd call
that a bug.

> The current tandem of D-Bus serivce files AND systemd service
> files for the same services is suboptimal, but appeared the most
> sensible thing for now, especially during the transition period where
> non-systemd systems are still common and matter. I think as soon as
> sysvinit and Upstart have been phased out on most distros we can rethink
> what we can do in this area.

I thought we were discussing the future here =)  So it makes sense to
work out how we expect all of this to work long term.