On 21.04.2017 21:31, karl@??? wrote:

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

If you dont want the service to daemonize itself, a debug flag doesn't
seem the correct approach, just a workaround. So they should at least
implemented some --foreground option that just prevents daemonizing,
but doesn't enable extra logging.

And here we are - lots of code duplication in all the individual
daemons. And operators have to look up how to actually call it in the
individual case. We could consolidate that into exactly one place.
(actually, I'd prefer services never daemonize themselves and always
leave that to a separate program of operators choice)

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

You're assuming that everybody implements an '-f' switch, and it's
always exactly '-f' - that flag could mean something completely
different (perhaps f for file). Again and again, operators have to
look up the manpage and be careful not to mix things up.
(or even patch up services that don't even have that flag yet)

With that library function, we have all of that consolidated in
one place and don't even have to change any command line syntax
anymore.

>> 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" ?

Sure, best practices would be nice, but then we can run into problems
like -f already used for something else. And again the operator needs
to handle it individually in his startup scripts / service rules / etc.

The best practice could also state: "please use that library if can,
and leave the rest to the operator / distro". Or perhaps "don't ever
let your programs daemonize themselves".

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

That would be nice, too, but I would put it into a different library,
and certain point the program would still carry the code looking at the
flag and deciding whether to daemonize. Yes, not much code (OTOH:
rewriting to do the command line parsing by the lib would be more
invasive, and you'll have trouble if -f is already used otherwise),
but we'd have it consolidated in one place and operators can easily
replace that whenever they feel necessary.

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

Same as above.

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

Actually, applications should either use syslog (except for debugging)
or just use stderr and leave it to the daemonizing/monitor program.

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

Well, lots of developers see the need for having such an reporting.
I, personally, never really had a real usecase for that, but these
folks want that, and therefore use the only API they have - systemd.

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

That would be a much wide scope. I was just trying to design a sane
API for what many applications link in systemd now.


--mtx