Bug#727708: upstart and upgrading from sysvinit scripts
Steve Langasek <vorlon@debian.org> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: