Re: [RFC] inetd(8) changes proposal

[tlaronde%polynum.com@localhost]

Le Wed, May 31, 2023 at 08:42:11PM +1000, Luke Mewburn a écrit :
> On 23-05-31 03:54, Robert Elz wrote:
>   |     Date:        Tue, 30 May 2023 21:03:21 +0200
>   |     From:        tlaronde%polynum.com@localhost
>   |     Message-ID:  <ZHZIeeECkpwVtnbB%polynum.com@localhost>
>   | 
>   |   | Do you think that SIGINFO is sound as the signal to obtain a config DUMP in
>   |   | the syslog?
>   | 
>   | First, dumping config to syslog seems like an odd thing to do at all, I'd
>   | normally expect it to be dumped in a file instead (something in /tmp
>   | perhaps, or where defined in the config file perhaps),
> 
> Over years of developing and maintaining various long-running
> services/daemons on various work systems that run for long periods of
> time, we've developed a convention to log a bunch of pertinent
> configuration on startup, and when the configuration reloads (if reload
> is supported) - either via SIGHUP or dynamically when configuration
> changes, depending upon the service and its implementation history.
> In some cases we just log what's change from compiled-in defaults (on
> startup) or changes from previous configuration before the reload.
> 
> Working with our support team and customers we've found that the
> practice of having such configuration in the log with the other messages
> from the service is quite helpful for debugging issues or confirming
> configuration especially if it's been running for a long time and the
> configuration has been changed since startup (without a reload).
> 
> We also have a convention of logging a "starting" event once the service
> has validated its options and configuration and is about to actually
> start work, "stopping" when shutting down (with a summary of the error
> that triggered it, if any - more details of the event is usually found
> in a previous log message), or "terminating by signal %d" if a signal
> (with appropriate set default handler and re-raise of re-raise of the
> signal, so that ^C in a shell loop actually stops).
> 
> These conventions may be useful here, or not. Just food for thought.
> YMMV :)

I think that this is important because following some convention helps
who is reading a log to grasp easily what is going on (or not...) and
helps scripting the log.

So I will go with these words (and case).

> 
> 
>   | But that's independent of the signal used to make it happen, that
>   | could be SIGINFO, which normally makes a process list its current
>   | state (what it is doing) - and for that knowing what config inet is
>   | serving could be considered part - but that is also typically a lot
>   | more than SIGINFO generates (usually just a line).   Personally
>   | I'd probably pick a different signal for that, but I am not sure which.
> 
> Yes, SIGINFO is really intended for foreground apps receiving a signal
> from the tty (e.g., I use ^T in tcsh) to display a short line with
> status, rather than services/daemons logging to syslog.
> 
> E.g., 
>   lukem% ^T
>   [ 6909969.1505419] load: 0.00  cmd: tcsh 2750 [0x4bb99a/4] 0.31u 0.28s 0% 1456k
> 
> SIGINFO support has been added to various other applications over the
> years: dump, gzip, ftp (etc). According to CHANGES.prev I sent a patch
> to implement TIOCSTAT in the tty driver in ~ 1993, but I don't recall
> what inspired that patch; maybe it was just tcsh's optional support for
> SIGINFO / TIOCSTAT. (I certainly didn't invent the idea).
> 
> 
> As to what signal to use. Maybe USR1 ? Or just leverage off the idea
> to log on (re)load the pertinent configuration.
> Maybe add a -D flag to enable debug without foreground
> (-d enables debug and foreground together), and then dump all the
> configuration.

I think that if, in other circumstances, this kind of info has been seen
to be relevant, I will go with dumping the successfully parsed config
that is about to be served to syslog (in every case; since if it is
useful when doing remote support, it can't depend on the flags given
when starting the daemon) and then add only a signal SIGUSR1 for
switching to the fallback config.

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