On 18.04.2017 14:46, k...@aspodata.se wrote: > Why srvmgt_daemonize(), use -f and daemon() and you'd be fine in > either camp, end case.
I've had the impression that daemon() wasnt't good idea for everybody, and there might be some need for anyone doing something these. So I proposed to move that out to some library, which the operator easily replace, w/o touching the application itself. (patching up libc to their needs isn't quite what operators do ...). That '-f' switch would be in the lib in a different form, eg. via env variables. My goal here is not voting for any particular way of daemonizing, service monitoring, etc, but just to provide an abstraction layer, so all that stuff can be moved out of the individual application. All the srvmgt_daemonize() call tells is that after that point the process will be daemonized - whatever that *actually* means in the exact setup (which is up to the operator's choice). This is *only* for the usecase where an service wants to have a straight line at all (eg. before that it might print out error messages to stdout). Those who don't need that at all, probably just run in foreground and delegate daemonizing to the caller (monitor, start-stop-daemon, etc, etc, etc) Certainly, everybody can implement the '-f' switch on his own (and it shouldn't be so difficult), but all of that repeated work (and the operator's work of reading manpages to find out which exact parameters he has to pass to an individual program to switch it on/off), could be saved if there was a single point for that. If you (as a service author) don't wanna use that, it's still your decision. > 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 ? It could even detect (eg. via env variables) whether it's already suid'd and then not even try and fail, it could fetch the target uid/gid from env, instead of having it's own (application specific) config or cmdline options. Again, consolidating repeated code into one place. Nothing more, nothing less. Similiar to srvmgt_daemonize(), it's only meant for cases where the service can't be started with the final uid/gid in the first place. > 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, There might be cases when the process being alive doesn't necessarily mean it's ready to serve (usually it takes *some* time). By the call, the application can tell it to the outside world (however the actual signalling might happen, and who might listen). NOTE: I'm just proposing an *API*, *not* an particular implementation. All I wanna get is that individual applications have an API (and ABI) to do these things w/o ever having to care whatever init system, service monitor, etc, there might or might not be. And the actual implementation shall be replacable w/o ever recompiling applications. --mtx _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng