On 07/08/2015 14:58, Rainer Weikusat wrote:
There's obviously a TOCTOU race here because "A is ready now" doesn't mean "A is still ready" at any later time.
Of course. That's why you need a supervisor to receive death notifications and publish them to whomever subscribes.
If there's something B can't do without A, it can't do that but it should try to cope as good as possible, be it only by retrying until A becomes available or delaying any 'expensive steps' until A became availabe.
That's why you run B under a supervisor: worst case, it will be retried. This does not preclude optimizing the common case, which is "A will succeed at some point, don't try starting B before that point".
But since the whole situation is hypothetical, this is nothing but a speculation.
It may be hypothetical to you, but it's very real to some people. It has been very real to me in a few professional environments.
start-stop-daemon is a less ambitious "solve everything somehow related to process startup in one program" (or a set of tightly coupled programs) and that's something I consider to be the wrong approach.
So do I.
| daemon chdir / monitor -n ca-server u-listen -g $GROUP -m g -l "$SOCKET" ca-server
I agree with your script skeleton, except on this line. Here, your instance of "monitor" is forked by your script. It can behave differently when you run your script by hand from when it is run at boot time. Also, "monitor" itself is not monitored; if it dies, you can't control ca-server anymore. And despite you not believing in dependencies, this is important. If "daemon" or "monitor" do not support readiness notification and return as soon as their child is spawned, ca-server may not be ready when your script returns, and if some ca-client is started right afterwards, it will fail. True, it will be restarted by "monitor" until it succeeds, but it's polling that can be avoided by proper dependency management.
As someone else pointed out, the control flow code could be abstracted away into some kind of 'universal init script' and individual ones would just need to define the start and stop commands.
That, or they may need to define service directories for a supervision system. Just sayin'.
1) Keep a relatively simple init which kicks off execution of commands in response to 'change the system state' request and nothing else (get rid of as much of /etc/inittab as possible at some point in time) 2) Generally, keep the run-level directories, but with better management tools. 3) Keep using the shell for everything it can easily handle. It's a highly-level programming language capable enough of handling the job. "But I don't want to learn an additional programming language, especially not one which looks like THIS and was designed in the 1970s!" is not a sensible reason for discarding it. Programming has its fashions and fads, just like everything else, but since "90% of everything is crap" 'new stuff' is mainly going to be just as bad as 'old stuff', only in a yet unknown way. 4) Provide the acutally missing features, ie "demonstrably required ones" in form of additional tools which integrate with the existing system.
You keep hammering that down as if 1), 2), 3) and 4) were not obvious to me. Would it be possible for you to stop feeling threatened by what I'm saying and realize that we're after the same goals, so we can have some constructive discussion ? If you can't, I'll simply let you argue in front of a mirror and go back to coding. -- Laurent _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng