Bug#727708: init system thoughts
On 18 January 2014 17:19, Russ Allbery <rra@debian.org> wrote:
> 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.
I think this would be most analogous to the "complex conditions" bit,
where you'd say
start on Y and Q
so that it will only be started when event "Q" happens if "Y" has also
already happened. I don't see how you'd prevent it from being manually
started without a prescript checking for Y though, but I'm not
entirely sure if that bothers me -- if I'm manually telling it to
start a daemon, that's configured not to automatically start some
thing it needs, do I care that much if I get an error from upstart or
the daemon itself?
Of course, upstart's "complex conditions" are documented not to work
the way you'd expect, so that's not entirely a solution. I could
easily imagine the complex condition support being enhanced to work to
fix the behaviour described in [0] and to also block manual starts of
the service prior to events happening, but that's not something that
exists now afaics. And the CLA's essentially the opposite of saying
"patches welcome"...
(Personally, I think I'm convincing myself that in an ideal world I'd
prefer the event model. upstart doesn't seem to implement that
sufficiently though at this point. Sigh, now I'm imagining an event
based init system written in haskell...)
Cheers,
aj
[0] http://upstart.ubuntu.com/cookbook/#restarting-jobs-with-complex-conditions
--
Anthony Towns <aj@erisian.com.au>
Reply to: