Enrico Weigelt:
> 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,

a, If you have that impression, then why daemonize() which sounds as
the same thing ?

b, No it isn't. That's why the -f, which is nice to have when debugging.

> and there might be some need for anyone doing something these.

The any other thing I can think of is running in the foreground and
"logging" to stdout/stderr, and possible being able to receive
commands via stdin.

> 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 ...).

if (do_daemon) { daemon(0,0); }

isn't much code to justify a lib entry, so what else is there in it to
lure a daemon writer to use it ?

> That '-f' switch would be in
> the lib in a different form, eg. via env variables.

Yes, it's messier to pick just the -f from argc/argv in a lib than
calling getenv().

> 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.
...

Well, that's fine, but replaceing -f and daemon() with your entry
doesn't seem worth it. Maybe it's better to write up some
"best practices" ?

> 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.

Then perhaps it's better to make it easier to use "standard"
command line options, and put that in a lib. E.g. a few funcs. that
parses argc/argv according to some data, extracts values, puts in
default values, prints error messages, usage text or version
strings without all the usual mess with option handling.

> > 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.

I think it is more fruitful in that case to write a lib that unifies the
command line, then environment and the config file handling, and make
it easy for the daemon writer to use it. In that kind of lib, you could
include default options for things like to daemon or not, uid/gid,
and where to log things.

I, as a daemon writer can see the value in having that handling defaulted
to some lib, and by it you can introduce default handling for -f and
--uid/--gid, so a possible monitor can set that what it to whatever it
wants.

Also of value could be a lib that unifies logging, or rather removes the
distinction between logging to syslog(), to a file or to stdout/stderr;
possible with default callback for SIGHUP to reopen/rotate log file.

You have to introduce what you want the other way around.

> > 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.

Yes, and as a intermittent daemon writer, I try to understand why I
should use it. If I cannot find any reason then maybe we should think
of something better.

> 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.

There are two things,
1, the monitor needs
2, the (possible monitored) process/daemon needs

To a daemon writer, point 1 is simply uninteresting. To get point 1
satisfied, you have to provide something that first and formost
fulfill point 2, and by providing for point 2, you in your lib, can
introduce things that makes it easier for the monitor.

So, instead of your proposal, I propose a lib that streamlines the
dull tasks of option/env/config_file, logging, and possible signal
handling. With it you can introduce things that is helpful for a
monitor.

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57