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

Lennart Poettering lennart at poettering.net
Wed May 6 09:35:15 PDT 2015


On Wed, 06.05.15 09:16, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> On Wed, May 6, 2015 at 5:52 AM, 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?
> >
> 
> What about adding option --define-only (I do not care about actual
> name) that adds unit definition but does not start unit? Then you can
> define any number of transient units and then "systemctl start" them
> later.

This is incompatible with the GC logic. We drop unreferenced units
agressively as soon as they are not active, not failed and not
referenced anymore... And we really should continue to do so.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list