Re: [RFC] inetd(8) changes proposal

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

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.

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.


Luke.