On 24/09/2015 17:51, Rainer Weikusat wrote:
> 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.

Five minutes? And you think it's acceptable? Sorry, I don't have five
minutes to waste every time a program fails. Also, this is 2015: if a
program isn't responsive within 30 seconds, users will come knocking at
your door raging - and they will be right.


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

And that's why there is readiness notification, in order not to start
program B before program A *can* actually serve. s6 is the only process
supervision suite handling readiness notification right, thank you for
underlining this. :)


> 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

You mean, removing the mounts from your service manager? Sure, you
can always do everything by hand. And if performing the mounts depends
on something else, such as insmoding a kernel module, then you also
need to do that something else by hand. And so on. Basically, you
never need to use any tool if you're doing the tool's work yourself -
you're just making it harder on yourself. /shrug


> 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[*]

If the "mount filesystems" example cannot convince you, nothing will,
so I'll stop there.


> [*] 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.

Yes, everything can fail, processes can die, the network can go down,
yadda yadda yadda. It's still sensible to optimize the common case.

--
Laurent