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

[Andrei Borzenkov]

В Wed, 6 May 2015 18:37:00 +0200
Lennart Poettering <lennart at poettering.net> пишет:

> On Wed, 06.05.15 05:52, Ivan Shapovalov (intelfx100 at gmail.com) wrote:
> 
> > On 2015-04-24 at 11:10 +0200, Lennart Poettering wrote:
> > > On Fri, 24.04.15 04:07, Ivan Shapovalov (intelfx100 at gmail.com) wrote:
> > > 
> > > > - do `systemd-run` twice and somehow set up the dependencies 
> > > > between
> > > >   two transient units
> > > 
> > > I'd be happy to take a patch that allows configuring deps for
> > > transient units when constructing them.
> > 
> > Hi Lennart,
> > 
> > I've just done this (also added manager-side support for
> > JoinsNamespaceOf= and RequiresMountsFor=, while at it). However, this
> > turned out to be insufficient for my usecase.
> > 
> > I have to start two transient services, say, A.service and B.service,
> > and
> > 
> > - B.service "needs" A.service
> >   (i. e. B.service Requires=A.service and After=A.service)
> > 
> > - A.service must be stopped as soon as B.service exits
> >   (i. e. A.service BindsTo=B.service)
> > 
> > And there is a contradiction: I can't make a dependency on an
> > inexistent unit.
> > If I create A.service before B.service, I can't set BindsTo=, and if I
> > create B.service before A.service, I can't set Requires= and After=.
> > 
> > Locally, I've solved this by allowing inverse dependencies to be set
> > over the bus. That is, I make B.service BoundBy=A.service. Is this
> > acceptable for upstream?
> 
> Ah, Yuck. Grrr.. Hmpf.
> 
> I figure the best way indeed is to allow reverse deps to be passed
> when using transient units. Not pretty, but probably OK. But please be
> careful, and do no blanket open up all kinds of deps, just those where
> there's a valid case for them, like in yours above.
> 

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.