[PATCH 0/5] Support service activation through Upstart
Scott James Remnant
scott at netsplit.com
Sat Dec 25 07:29:01 PST 2010
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:
>> and make --systemd-activation an alias for
> 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:
>> 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
No, they make the services behave the same.
More information about the dbus