Re: [RFC] inetd(8) changes proposal

[Luke Mewburn <luke%mewburn.net@localhost>]

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


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


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, 



cheers,
Luke.