On 18 January 2014 17:19, Russ Allbery <r...@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 <a...@erisian.com.au> -- 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/cajs_lcv6omn-ddujqbqeqyfhztax9s_wrfnh2ropwmjqw0y...@mail.gmail.com
