On 18/04/2017 at 14:46, karl@??? wrote:

[...]

> Why srvmgt_daemonize(), use -f and daemon() and you'd be fine in
> either camp, end case.

This is well *if* the daemon has -f and does daemon(). I know the
only programs that do not do it are those that were not intended to be
run as daemons, still from time to time people do that, with netcat for
instance.

> Why srvmgt_droppriv(), either accept that the process set's it itself
> or force it to some uid:gid, what is it more to it ?

"What if you do not trust the program?" (quote)

Then you answered yourself already: "force it to some uid:gid": this
is the monitor's job. One of them.

> Why srvmgt_report_state(), just do a normal query to the process and
> you'll know if it is ready to serve you or not,

This way you only know that the process is up, not that "it is ready
to serve you or not". I'm sure you've had experiences of processes that
are running but are not delivering the services you expected from them.

> if you want to know
> if it is up to speed, do a benchmark, if you want to test the
> integrity, do a regression test; what is it more to it ?

Knowing if it is ready to serve you or not", for instance. Learning
if it got stuck on something, if that is temporary or definitive, if
it's best to kill it or maybe raise it's allotted max number of open
files. Or just write a line in the logs and let the sysadmin pick it up
and see for himself what to do.

If you want an init that only launches programs and daemons and as
soon forgets all about them, fine. I'm not in principle against such a
minimalistic init. Just don't call it a monitor thought, 'cause it ain't.


Alessandro