Re: [RFC] inetd(8) changes proposal

[tlaronde%polynum.com@localhost]

Le Wed, May 31, 2023 at 09:57:00PM +1000, Luke Mewburn a écrit :
> On 23-05-31 13:12, tlaronde%polynum.com@localhost wrote:
>   | > Also, on 23-05-30 21:03, tlaronde%polynum.com@localhost wrote:
>   | >   | (When checking, so even with -C, nothing is written via
>   | >   | syslog since, then, inetd is not a daemon but just an utility---a syntax
>   | >   | checker---printing messages on stdout or stderr and a inetd daemon could be
>   | >   | serving at the very same time: so don't spoil its log.)
>   | > 
>   | > I don't consider inetd in "check" mode using syslog (except when in -f
>   | > foreground of course) as "spoil[ing] the log"; the relevant entries will
>   | > have a different process ID in the log and sysadmins and log processors
>   | > are quite familiar with dealing with parallel streams of logs from the
>   | > same service with different process IDs, 
>   | 
>   | But inetd used in check mode is probably to try to validate a candidate
>   | config in the current process to be written. If it is actually used,
>   | the config parsed will be syslogged when actually loaded.
>   | 
>   | So I think when using inetd in check mode, it is an utility and the
>   | config will go to stdout, and the errors about the parsing to stderr
>   | (and when trying to run, the syslog will have only the information about
>   | failure to parse, or success and config dump, not the details of the
>   | parsing since these failures can be explored at length by using inetd in
>   | check mode).
> 
> IMHO, if check + -f foreground; errors to stdout/stderr,
> and if check + (background default); output to syslog.
> In any case, success is 0 status, failure is non-zero (or signal raise).
> 
> If check mode is used in an rc.d script (for example), dumping a lot of
> errors to stderr can ruin "clean" rc.d output, and if the stderr errors
> occur at startup, you may not have easy access to errors printed to
> stderr on boot, whereas you generally have the syslog.

Since I have replied in chronological order, and it might be difficult
to gather the pieces in the right order with a hierarchy of threads, I
will restate (or state more clearly) what I have in mind in this area:

inetd(8) called with just '-c' will only validate or invalidate a config
without writing anything neither to stdout, nor to stderr and not via
syslog.

With '-C', it will write the "explained" (all comments stripped; all
addresses explicit) config parsed if successful to stdout (and nothing
to stderr).

If, with '-[cC]' the '-d' flag is also given, debugging informations
about the parsing will be sent to stderr.

When not checking, the first step of inetd(8) will be to parse the
config before doing anything. If the config is not valid, a message will
be written via syslog stating that the config is rejected and, depending
on default behavior or resilient mode, it will whether exits (logging
via syslog that it is exiting on error) or fallback to the alternate
fallback config.

But, even with '-d', the debugging informations about the parsing of the
config will not be written via syslog since it will, IMHO, add too much
hay around the needles.

Furthermore, if the parsing succeeds, we don't care about the debugging
information. If the parsing failed, invoking 'inetd -cd config' will
give all the informations to the one in charge of fixing it. And if
"config" has vanished in the meantime, the debugging informations would
have been useless altogether, since the config will have not been
"serviced".

> 
> Again, we've found both helpful at work. Originally we used to just
> print daemon startup errors to stderr. We eventually changed to
> duplicate to syslog until we know if we're foreground/background mode or
> not. This isn't a NetBSD convention per se, although I could write up in
> more detail the conventions we do use and pass them around separately
> for consideration/refinement for NetBSD services/daemons.
> 

For the daemon (not invoked as a parse checker, even if the daemon
always checks the config before executing the directives), the messages
will go via syslog.

The remaining question is whether, with a successful parsing when
running in daemon mode, the config should be dumped via syslog (I
finally think so) or if another signal has to be accepted to only dump
the config (to syslog since you think there may be problem when dumping
to a file in /tmp) via syslog only if requested to do so.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C