karl@??? wrote:

> Given the choises given, it seems that the target of the monitor is
> network servers. Couldn't the monitor find out the ready_local,
> ready_all and shutdown by itself by monitoring which ports are open ?

...

> And, what if the monitor cannot trust the program it monitors ?
>
> Given the lib suggestion, it seems that we are trusting the program.
> But what if if we don't know if we can trust the walues provided by
> the program, the we have to check what the program is really doing,
> and then the lib have no value, isn't that so ?

Well there isn't really any easy way round the "don't trust my programs" problem. Your suggestion of monitoring open ports doesn't get round it - what if a program opens up port 80 but just "does nothing" with any connections it gets ? One way you see that "port 80 is open" and assume the service is up, the other way you get a notification that the service is up and assume that it's up.

I really don't see how you can work around that at the supervisor level.

Also, if you are going to detect a service as up just because it's opened one or more ports, that means the supervisor needs to know in detail what each program does. That goes against all good practice in terms of decoupling functions and leads to the systemd problem of massively interlinking stuff that doesn't need to be linked.
Not to mention that there may well be services where a port (or socket) is opened before the service is actually ready to accept requests. So then you are into the supervisor having to know how to talk to each service so as to be able to make a request and see if it gets a sensible answer.


But then I'm one of those generally happy with SysVInit style booting. It's easy to understand, it's generally reliable, it's fairly easy to debug if something isn't right. But I also recognise that others aren't happy and if they want to use something else then that's OK by me - as long as what they propose isn't something that "infects" stuff I want to run under SysVInit.