[PATCH 0/5] Support service activation through Upstart

[Scott James Remnant]

On Sat, Dec 25, 2010 at 2:35 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:

>> 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.
>
Well, you need to pick which of systemd or Upstart is to receive the
signal right?  So rather than hardcode the names of those services, I
figure it's better to just pass it on the command-line.

That way if the OS X or Windows people want to do the same, they don't
need to patch D-Bus again.

>> 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).
>
How does this extend the D-Bus .services files in any way?

> Also, the env stuff is is relevant only for Upstart, and an abstract
> interface should not expose this.
>
I can't work out why the D-Bus Activation Environment _isn't_ relevant
to systemd? When someone calls UpdateActivationEnvironment - how does
systemd get that to any future activated services?

> 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.
>
The whole point of passing Exec= and User= like that is so that
they're *not* different.

>> 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.
>
No, they make the services behave the same.

Scott