[PATCH 3/3] activation: optionally, use systemd for system bus activation

[Lennart Poettering]

On Wed, 07.07.10 17:47, Colin Walters (walters at verbum.org) wrote:

> 
> On Wed, Jul 7, 2010 at 5:01 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> >
> > I actually like to keep everything on one bus. The bus is just a
> > transport, and i see little need to split off a seperate connection only
> > for the activation stuff.
> 
> To be clear - I wasn't suggesting a separate connection *just* for
> activation stuff.  We could move system bus eavesdropping over to
> that, for example.  People have also asked for interfaces to dump the
> match rules from the bus, etc.  The point is that this interface would
> be considered unstable/hidden, separate from org.freedesktop.DBus.

Hmm, but wouldn't it be more appropriate to do that distinction via
interfaces or so than via sockets? I.e. to me it sounds a lot more
dbus-ish if stuff like that would just live on
org.freedesktop.DBus.Private or org.freedesktop.DBus.Unstable, but on
the same bus?



> > Note that keeping things on a single bus has a big advantage: the
> > activation logic can be used for "activating" systemd itself.
> 
> I'll have to think about this a bit more.  But note you can do any
> synchronization you want over a management interface too.

Sure. But I like the idea to treat systemd almost like any other
activated client here, and handle this within the usual activation logic.

I mean, we could certainly establish a private, synchronous channel for
communication with systemd. But this will still make the activation
logic I explained in my earlier mail necessary as well, since other
clients might also want to talk to systemd via D-Bus, and we need to fix
the activation race there.

> > To make it possible to boot the same system with systemd and without
> > systemd: the systemd .service file would set --systemd-activation and
> > thereby tell D-Bus that it should send activation requests to
> > systemd. And the SysV init script would not set it, so that when D-Bus
> > is started with a traditional init system this activation hookup would
> > not happen.
> 
> Couldn't we just notice whether we were started with the systemd:
> address family then?

Well, these are two seperate things I believe: there's one thing which
is socket activation for dbus. And there's another thing which is the
bus activation glue between dbus and systemd. The former uses a
communication channel that is generic enough to be used within other
systems too. The latter however defines messages which only really make
sense in the context of systemd.

Or with other words: I still hope that should Scott indeed add socket
activation to Upstart as well he'd be willing to support the $LISTEN_FDS
logic too. However, the bus activation glue makes no sense for him to reuse.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.