Systemd unit file implementation questions (ypbind)

Michal Hlavinka mhlavink at redhat.com
Fri Apr 15 05:03:13 UTC 2011


On Thursday, April 14, 2011 19:54:36 Lennart Poettering wrote:
> 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

Why is "After=" required here? If B Requires A it seem obvious that B 
should be started After A (if there is no socket magic).

> 
> 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.

That's not exactly what I'd like to know. Lets say there are services A and B.
When B is started, A must be running, so B requires A, but when B is stopped, 
it should stop A. So A is started only on demand, but it should not be running 
if there is nothing that requires it.



More information about the devel mailing list