[PATCH 0/5] Support service activation through Upstart

[Scott James Remnant]

On Fri, Dec 24, 2010 at 8:10 AM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> I think it would make sense to extend the .service syntax with two options:
>
> ActivationByManager=true|false
> ActivationString=xxxx
>
> and then make SystemdService=xxx an alias for ActivationString=xxx.
>
This makes sense to me, and would solve both of our cases.

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.


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

That way nothing would need to be hardcoded into D-Bus about
activation managers.


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)

Maybe this forbids future expansion of the .service file, and we
should instead go with something like:

    org.freedesktop.DBus.Activation.ActivationRequest(
            out STRING request,    // The string given in ActivationString
            out ARRAY of DICT<STRING,STRING> entry,
            out ARRAY of STRING environment)

Where entry is the parsed .service file keys.  I *do* particularly
want the Exec and User keys, and I imagine they might be useful on
non-Linux platforms too.

You could ignore these fields for systemd, of course.


The response signal in case of failure could be:

    org.freedesktop.DBus.Activation.ActivationFailure(
            out STRING request,
            out STRING code,
            out STRING message)

Which matches your existing one.

Scott