Steve Langasek <[email protected]> writes: > This still leaves the concern I have about start-time races. According > to systemd.unit(5), using 'Requires=', as Uoti suggested to Russ, does > *not* guarantee ordering:
> Note that requirement dependencies do not influence the order in which > services are started or stopped. This has to be configured > independently with the After= or Before= options. If a unit > foo.service requires a unit bar.service as configured with Requires= > and no ordering is configured with After= or Before=, then both units > will be started simultaneously and without any delay between them if > foo.service is activated. Well, one can certainly add a Before= stanza to the socket file to resolve this. However, whether this is necessary again revolves around the interpretation of a few bits of unclear documentation. My understanding from the documentation is that all of sockets.target is always started before any services that are part of multi-user.target, so there's no need for these explicit dependencies. And, indeed, that appears to be correct given the contents of the various target files. multi-user.target depends (with After=) on basic.target, which in turn depends (with After=) on sockets.target. sockets.target happens very early in the boot. I think you only have to worry about this ordering if you're writing an early-boot service unit that will be started before basic.target for some reason. It would, however, be nice if this were more clearly stated, since the guidance to the author of the unit file about what dependencies one should or should not explicitly add is a bit sparse. In particular, I wonder if there is an implicit After= dependency in a service unit on a socket unit of the same name (which would make sense given how Sockets= works), or if that's something that one should explicitly add. I should note that I think Uoti's point about Requires= is more about ensuring that one can't create weird situations where the socket is inactive but the daemon is active, which I was able to create in testing because I didn't have that setting. I can confirm that adding Requires= now does the right thing: if the socket is explicitly stopped, the service is stopped as well, and if the service is then started, the socket is also started first. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
