Re: Systemd unit file implementation questions (ypbind)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 15.04.11 07:03, Michal Hlavinka (mhlavink@xxxxxxxxxx) wrote:

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

Requirement and ordering dependencies in systemd are orthogonal. 

This is useful at various places. 

For example, you can have req deps without ordering, which is for
example handy for cases like this: think CK and gdm. gdm uses CK, but
due to bus activation doesn't need to be started after it. In fact we
can get away without not having any dep between the two, because bus
activation would start CK as soon as it is needed. However, if we add a
Wants dep without any ordering from gdm to CK we can optimize things a
little: CK would be started as soon as possible, but gdm not delayed for
it. There's a big chance then that CK might already be ready to process
requests at the time gdm needs it. 

Or you can have a req dep with a Before ordering. Think an sql server
plus a monitoring service for the sql server. The monitoring service
should always be started when your SQL server is started, too. But the
monitoring service should be started after the SQL server, since it
connects to it. 

And thus you have use cases for all three cases: Wants/Requires plus
After, Wants/Requires with no ordering, and Wants/Requires plus Before.

And of course, very often an After/Before without Wants/Requires also
makes sense.

If you put all this together then it is easy to see why ordering and
requirement are made orthogonal in systemd.

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

In general we try to avoid work if we can. That includes that we don't
stop services unless we have to. Often it is nicer to just leave a
service running when it hangs in a poll() and is swapped out than to
start/stop it all the time.

That said, systemd wouldn't be systemd if it wouldn't cover your case
too, if you really want. Set "StopWhenUnneeded=yes" in a unit and it
will be stopped as soon as nothing runs anymore that needs it. Defaults
to "no".

But I think in the general case this isn't really something you want to
use much.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux