On 23-05-31 03:54, Robert Elz wrote: | Date: Tue, 30 May 2023 21:03:21 +0200 | From: tlaro...@polynum.com | Message-ID: <zhzieeeckpwvt...@polynum.com> | | | 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, tlaro...@polynum.com 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.
