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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
