On 18.04.2017 14:46, karl@??? 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