[PATCH 0/5] Support service activation through Upstart

[Lennart Poettering]

On Sat, 25.12.10 15:29, Scott James Remnant (scott at netsplit.com) wrote:

> > 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?

Because your env stuff is passed along only if the service is activated
by Upstart, but not otherwise. Hence the stuff encoded in the .service
file is handled differently in its effect on Upstart and on the classic
activation.

> 
> > 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?

We do not support that. The D-Bus activation env is used only if dbus
itself activates something, which I find kinda appropriate.

I think quite a few folks agree with me that allowing updating of the
env for executed services like this is a bad idea anyway.

In systemd we do support dynamic changes to the global env block all
processes inherit, but for the only reason to allow changing of i18n
settings during runtime. In fact, originally it was my intention to call
the env var updating dbus call SetLocale() instead of SetEnvironment().

In systemd we have multiple triggers for starting services, and very
often these happen simultaneous and it is hence not necessarily clear
which comes first (example: avahi is started via bus and socket
activation), and we want to make sure that under no circumstance the
effective order of these events causes the service to be started with
different parameters. So, if D-Bus turns out to be triggered first, and
the socket second, we need to make sure that the exec env is identical,
and hence it would be a really bad idea to import the dbus env block if
dbus-happens-before-socket but not on dbus-happens-after-socket. There
are many additional triggers (for example: user request, hw plug, or
simply boot-up), and in order to get a reliable boot-up that always
behaves the same at the same time of a parallelized execution this is
crucial.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.