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
