Anthony Towns <a...@erisian.com.au> writes:
> To emulate systemd dependencies in an event model (ie, X depends on
> Y), you'd need to do either:
> * change Y's job to say "start on starting X"
> * add "stop on stopping Y" to X's job description
> or
> * add a pre-start script to X in order to start Y first
> * add "stop on stopping Y" to X's job description
> The latter looks like it's the documented way of doing things. Neither
> of those seem particularly great -- I think that's due to upstart not
> letting you reverse event descriptions in the same way that systemd has
> Requires/RequiredBy statements. If you could say:
> * on starting start Y
> * stop on stopping Y
> in X's job description, by contrast, I think that would be a fine way of
> declaring a "dependency" from X to Y without leaving the "event"
> model. Not having a simple way of specifying this sort of dependency
> seems pretty weak on upstart's behalf.
It's worth noting that even the second solution above does not allow
simulation of systemd's Requisite=, only Requires=. Now, normally
Requires= (when starting X, start Y if not already started) is going to be
fine, but I can certainly imagine cases where Requisite= (if Y is not
started, just immediately fail startup of X) is the behavior one actually
wants. I'm not sure how you would pry that behavior out of upstart's
event model short of bypassing the event structure entirely and just
writing an explicit check in shell in pre-start to ask whether Y is
running. Which, of course, one can certainly do, but it means that
information is now stored outside the dependency graph in
difficult-to-parse shell and doesn't show up in analysis tools, etc.
It took me a long time to wrap my mind around the objections to upstart's
event model, but now that I'm starting to understand the exception cases,
I keep seeing more things that feel like they should be straightforward
but end up oddly convoluted when expressed in upstart's event model.
> It would probably also be nice to have a way of saying "when a new
> network comes up, reload/refresh service X" -- so that it could bind to
> new ports or whatever even if it was already running; that seems like
> the sort of thing that would be easier to specify in an event model ("on
> new-network-interface-started reload or start"), than in a dependency
> model.
That, however, is also a good point. This specific case is the place
where an event model does have a clear advantage. It looks like the
preferred strategy in the systemd model is to teach daemons to watch for
this themselves, which while certainly a good idea (most high-quality UDP
daemons I know of that care about binding to specific interfaces do in
fact do this), is decidedly non-trivial and hard to do portably if the
daemon doesn't already support it. Freebind sockets get one out of a lot
of the places where this is needed, but not all of them.
In general, it would be nice to move this sort of thing out of the daemon
into the init system. Given that there's already a system service that
knows when things like this happen, duplicating that listening code in all
the daemons isn't as appealing as just letting the system service inform
the daemons when it happens.
That said, I think the dependency model is a lot clearer in the common
cases, and the places where the event model is superior are fairly
unusual.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9ethi3u....@windlord.stanford.edu
