Systemd unit file implementation questions (ypbind)
Lennart Poettering
mzerqung at 0pointer.de
Thu Apr 14 17:54:36 UTC 2011
On Thu, 14.04.11 16:15, "Jóhann B. Guðmundsson" (johannbg at gmail.com) wrote:
>
> On 04/14/2011 03:36 PM, Lennart Poettering wrote:
> >> In man systemd.unit
> >> >
> >> > BindTo=
> >> > Configures requirement dependencies, very similar in style
> >> > to Requires=, however in addition to this behaviour it also
> >> > declares that this unit is stopped when any of the units
> >> > listed suddenly disappears. Units can suddenly, unexpectedly
> >> > disappear if a service terminates on its own choice, a
> >> > device is unplugged or a mount point unmounted without involvement of
> >> > systemd.
> >> >
> >> > ExecStop=-/bin/systemctl stop upsd-device.service
> >> > ExecStop=-/bin/systemctl stop upsd-monitor.service
> > Why ExecStop= here?
>
> It was meant as an either or.
>
> The BindTo= reference in the man page does not mention that it will take
> down with it any service bound to it when the service is stop.
Requires= and BindTo= both do that.
The difference between the two switches is mostly an ordering issue:
Let's say you have a unit A and a unit B. B requires A, and should be
started after A is up. So in B you say:
Requires=A
After=A
now, if you shut down A with "systemctl stop A", this will also stop B,
and it will do so in the inverse starting order. i.e. stop B first, stop
A second. BindTo= would do exactly the same here. The difference now
comes if for some reason A dies independently of anybody running
"systemctl stop A": should we then shut down B retroactviely? The
ordering would normally suggest that B goes down before A, but if A just
goes away on its own, then should we still shut down B? If you use
BindTo= that's what would happen. If you use Requires= it wouldn't.
So where is this interesting? If A is a device and B is a service, then
normally B should start after A is plugged in and be killed before A is
unplugged. By using BindTo= you can also make it be killed if A is
unplugged with B still running.
Lennart
--
Lennart Poettering - Red Hat, Inc.
More information about the devel
mailing list