[systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

[Ivan Shapovalov]

On 2015-05-14 at 22:31 +0200, Lennart Poettering wrote:
> On Thu, 07.05.15 04:37, Ivan Shapovalov (intelfx100 at gmail.com) wrote:
> 
> > On 2015-05-06 at 18:59 +0200, Lennart Poettering wrote:
> > > On Wed, 06.05.15 19:53, Andrei Borzenkov (arvidjaar at gmail.com) 
> > > wrote:
> > > 
> > > > I still think that being able to define and start group of 
> > > > units 
> > > > as one
> > > > unit (pun unintended) is better in the long run.
> > > > 
> > > > This really far exceeds original scope of systemd-run which was
> > > > "quickly start something under systemd supervision". When we 
> > > > have
> > > > complex set of units with interdependency either systemd-run is 
> > > > the
> > > > wrong tool for it or it should do it right, not paper over.
> > > 
> > > Hmm, you actually have a point, and we already *do* support 
> > > queuing
> > > groups of units, and that should suffice for this usecase, so 
> > > that we
> > > don't need to allow definiton of reverse deps.
> > > 
> > > This is actually already used for the time-based systemd-run 
> > > stuff,
> > > where we create both a transient timer and a transient service 
> > > unit
> > > and then start the timer unit.
> > > 
> > > Ivan, what you are trying to do hence should already work just 
> > > fine 
> > > in
> > > the lower level apis, using the "auxiliary" list of units that 
> > > the
> > > StartTransientUnt() bus call takes. systemd-run doesn't 
> > > generically
> > > open this up yet though (and i dont know how it could do so 
> > > nicely).
> > 
> > Yeah, auxiliary units could help here, though they suffer from the 
> > same
> > kind of problem: either auxiliary units are read from message and
> > created before the main one, or vice versa. The problems are the 
> > same
> > as with two consecutive StartTransientUnit calls.
> 
> Hmm, if , I think this should be fixable though. Already, allocating 
> a
> unit, loading a unit and starting a unit are three separate steps. It
> shouldn't be too hard to fix PID 1 to allow allocating all transient
> units to create in a group first, then in a second step load all of
> them, and finally start one of them. With such an order in place it
> should be easily possible to do what you want to do, no?

Yeah, makes sense. I'll try to do that in meantime.

BTW, regarding creating aux units from systemd-run(1). I guess it can
be done in two ways:

- "--aux-unit" parameter which adds another aux unit and makes all
following parameters (until another --aux-unit) set parameters of this
new aux unit (i. e. stateful command line);

- "--aux-units-from-file" parameter or something like that which reads
the given file and parses each line of it as a separate command line,
creating an aux unit from it.

The former would look like this:

$ systemd-run --name foo.service -p Wants=aux-1.service /bin/foo \
--aux-unit --name aux-1.service -p BindsTo=foo.service /bin/aux-1

The latter (in bash syntax) would look like this:

$ systemd-run --name foo.service -p Wants=aux-1.service /bin/foo \
  --aux-units-from-file /dev/stdin <<-EOF
--name aux-1.service -p BindsTo=foo.service /bin/aux-1
EOF

Would any of this be OK?

-- 
Ivan Shapovalov / intelfx /
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150515/27652c9e/attachment.sig>