Laurent Bercot <ska-devel@???> writes:
> 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.

If it starts working within less than five minutes, users will forget
about it faster than they could complain, especially for a system which
is usually supposed to be running. But that's actually a digression.

> 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.

Or you do trigger 'failure paths' which may not be nice at all. Eg,
according to a Solaris depenency specification I saw at some time in the
past, sending local mails on a Solaris system won't be allowed before
LDAP has been started. But there's really no way to predict this because
'starting program A before program B' does not mean 'program A will be
ready to serve program B by the time program wants to use its services'.

[...]

>> 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.

Provided a program is supposed to work this out on its own, this
information can be modelled as 'a dependency'. But you could equally
well modify rc.local to do a

mount-all-filesystem

before a

start-the-services

NB: Judging from past experience, I regard "configure the system such that
it's 'ready for applications" as userspace part of 'system boot'. After
this has happened, applications (of all kinds) can be started in
whichever way seems most suitable. But I'm not really planning to argue
about that, I'm interested in situations where 'service dependencies'
are actually useful. I'm convinced there aren't any but I'd gladly learn
that I'm wrong[*]

[*] In line of TOCTOU, there's a TOSTOU race here --- time of start is
not time of use which means things can change in between and 'TOS'
doesn't even guarantee that the intended situation ever existed.