[systemd-devel] Depending on services from a service unit template

[Paul Menzel]

Dear Michael, dear Andrei,


Thank you for replying.


Am Montag, den 27.06.2016, 15:37 +0200 schrieb Michael Biebl:
> 2016-06-27 13:49 GMT+02:00 Andrei Borzenkov <arvidjaar at gmail.com>:
> > On Mon, Jun 27, 2016 at 9:25 AM, Paul Menzel wrote:

> > > having a template for a service unit like `example at .service`, and
> > > starting several services from it, is there a way, to let another
> > > service unit require all services started from that template?
> > 
> > I do not think it is possible. In other direction it may work with
> > some workaround (i.e. make every instance of template be required
> > by specific services).
> 
> PartOf= in the template service might be what you are looking for.

From the manual page systemd.unit:

>        PartOf=
>            Configures dependencies similar to Requires=, but limited
> to stopping and restarting of units. When systemd stops or restarts
> the units listed here, the action is propagated to this unit. Note
> that this is a one-way dependency — changes to this unit do not
> affect the listed units.

So, it could indeed be what I am looking for. In my use case, it
doesn’t feel right yet though.

There are several instances of a Web application started from
example at .service. In front of it is the proxy HAProxy.

So in my reading, saying that the Web application instances is a *part
of* HAProxy, doesn’t totally feel/sound right to me.

Also, asking for `Requires=` was, that HAProxy seems to check the
configured backends to run, and refuses to start if they don’t. That’s
why, all the Web applications are required before the HAProxy start-up.

If I am not mistaken, `PartOf=` does not solve that problem.

Do you have another suggestion?


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160630/3b4a1247/attachment.sig>