[RFC] Common activation manager via external manager

[Lennart Poettering]

On Sun, 02.01.11 22:46, Scott James Remnant (scott at netsplit.com) wrote:

heya,

> Thanks to everybody who commented on my previous patch to add support
> for Upstart service activation alongside the existing systemd patch.
> Since Lennart and I both appear keen to agree on a common interface, and
> there is support from others for doing that, I present a new set of
> patches for comments that replace the existing interface with a common
> one.
> 
> I've followed Colin's suggestion that we always try to activate via the
> activation manager if one is present, rather than relying on the
> presence of a field in the .service file.  To allow the activation
> manager to deal with services it doesn't directly know about, the
> activation request includes the Exec= and User= lines from the .service
> file.

Hmpf, I don't think this is a good idea. Or, to say this with other
words, I don't want to support this in systemd. And this current
mechanism you propose would require me to.

Services should be introspectable in systemd even when they arent
started (heck, isn't it natural if people closely look at what they
start before they start it?). However, if the data about a service is
only passed along at the time of activation (i.e. the last moment
possible) we cannot do that -- We need that information before.

Hence: I think it is a bad idea to pass this along with the activation
request. if you really want to allow activation of dbus services without
having to manually configure them in native configuration files of the
init system, then at least do it properly: add an API to the bus driver
to expose all activatable bus services it read with its properties, and
include change signals and stuff. Given that the list of activatable
services doesn't change that often simply adding a single property to
the bus driver whith an array of structs with the service information
should be enough.

> In addition to allow activation of the session bus, the activation
> environment is included as well.

Again, this is a bad idea: if anybody uses this it is really
difficult to make a service activatable both via dbus and via some other
mechanism properly, in a fully parellelized environment: because
activation via dbus might cause a different env to be passed to a
service than activation via socket, hw plugin, manual user or at boot or
any other. 

Passing along environment blocks is a bad idea I believe and I will not
make use of it in systemd, and to be frank it surprises me that you want
to use that in upstart, unless you want ensure that dbus services are
only ever activated by dbus, and never by other means. because if you
do that then you make it impossible to load dbus services hat are
traditionally loaded by bus activation early, since you know that they
are used anyway.

Example: currently CK is started only via dbus, but it is almost
guaranteed to be activated during boot, since gdm uses it. If you rely
only on bus activation to start it, then it is started at the moment gdm
wants to use it, which is the last momemt possible and which means gdm
needs to wait for CK to start up. Much better it would be if CK could be
started much earlier, at the same time as gdm perhaps. And then when gdm
wants to use it, it might already be up, and if it isn't gdm would wait
for it, but most likely would have to wait for a much shorter time only,
since start-up is already in progress.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.