On 18/04/2017 at 14:46, k...@aspodata.se 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng