[PATCH 0/5] Support service activation through Upstart

[Lennart Poettering]

On Fri, 24.12.10 13:51, Scott James Remnant (scott at netsplit.com) wrote:

> 
> I couldn't find a rationale in the Mailing List history (and I read it
> all, even the "User Bus conclusions" thread that I thought would never
> end :p) for why you used a Signal instead of a No-Reply Method Call
> *but* we have a rationale in this thread - it means we only need to
> know a destination bus name, not the tuple of bus name and object
> path.

This is actually documented in the most fitting place of them all, in
the sources:

          /* OK, we have a systemd service configured for this entry,
             hence let's enqueue an activation request message. This
             is implemented as a directed signal, not a method call,
             for three reasons: 1) we don't expect a response on
             success, where we just expect a name appearing on the
             bus; 2) at this time the systemd service might not yet
             have connected, so we wouldn't know the message serial at
             this point to set up a pending call; 3) it is ugly if the
             bus suddenly becomes the caller of a remote method. */

So, there you have it. 

http://cgit.freedesktop.org/dbus/dbus/patch/?id=b3ed8675a4eba35c6a7f43a86a89f706ffe07f84

> So, building on the above, I would suggest that that we change the
> command-line switch to:
> 
>   --activation-manager=BUS-NAME
> 
> and make --systemd-activation an alias for
> --activation-manager=org.freedesktop.systemd1

Why make this configurable? The only reasons I could think of to make
the name configurable would be if a) services could only pick one name,
and hence we need to direct everything to the right name or b) you want
to allow multiple services to be around for activation. However neither
reason is valid or applies to D-Bus and hence I see little reason to
make the name configurable.

> As for the signal itself, there's a few bits of information you're not
> including, not least the activation environment, which I would
> certainly like for Upstart.  Would you be happy with the signal
> definition being something like:
> 
>     org.freedesktop.DBus.Activation.ActivationRequest(
>             out STRING request,    // The string given in ActivationString
>             out STRING name,       // }
>             out STRING exec,       // } keys parsed from the service file
>             out STRING user,       // }
>             out ARRAY of STRING environment)

Hmm, I am quite opposed to this. I think we are well advised not to
extend D-Bus .service files functionality-wise, to ensure that
regardless which method of activation you use the same behaviour takes
place. Or with other words: it's fine to shift around the place where
activation is executed (the ActivationString= can be used for that), but
it's a bad idea to make it behave completely differently (which I fear
the service stuff could trigger). 

Also, the env stuff is is relevant only for Upstart, and an abstract
interface should not expose this.

On top of that, i think it is a really bad idea to pass a different set
of execution parameters to an activated service if it is run by manual
trigger or by a dbus trigger. If you hence make this configurable in the
D-Bus .service file, then depending how a service is started it runs in
different modes, which is racy and bad style.

> You could ignore these fields for systemd, of course.

These extensions would basically mean that services might behave
completely differently when activated natively or via some init
system. That's something we should work against, not something to make
easy.

I can't say I am a particular fan of the complexity you are adding to
this.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.