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