On 24/09/2015 16:40, Rainer Weikusat wrote:

> Hence 'failure'
> is part of the normal mode of operation and proccesses trying to use TCP
> need to deal with that.

Yeah, well, if your favorite startup mode is to start everything at
the same time and say "eh, if it doesn't work, the program is supposed
to handle failure" then your users will give you funny looks, and they
will be right.

I'm talking normal use cases here, i.e. situations where the services
*will* succeed. In those situations, it is better to start everything
according to the dependency graph, because then you do *not* trigger
failure paths, which is nicer.
This does not preclude programs from actually handling failure when
it happens, but it's best if failure is the exception, not a normal
mode of operation.


> That's slightly different because it's obviously not possible to start a
> program stored in a file (which needs various other files to start)
> before accessing any of these files is possible (it's still subject to
> changes at runtime, though). But it's not necessary to declare a
> dependency on "the filesystem" in a dozen different files and then run
> some program in order to work out that "The filesystem namespace must be
> constructed prior to using it!"

And still, "the filesystem namespace must be constructed prior to using it".
No matter how you call it, that's a dependency, and that's what I'm talking
about. Now, you're free to start daemons logging stuff to /var/log/foo
before mounting /var/log, but the reasonable people among us prefer not to
do it. ;)

--
Laurent