Re: inetd(8): continue or exit on error?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Jun 02, 2023 at 01:21:15PM +0200, tlaronde%polynum.com@localhost wrote:
 > > I have not read most of the traffic yet, but I feel, fairly strongly,
 > > that inetd should _not_ exit, except (maybe) if the config is broken
 > > during its initial startup. It's a critical service.
 > 
 > So I will put together the result of the exchanges in the thread and of
 > my reading of the source:
 > 
 > Not stopping on an error was logical with the old syntax since _all the
 > directives were independent_: failing to read a line for a service
 > shouldn't have the side effect of failing to serve the other services.
 > 
 > But this assumption does not anymore with the new syntax: the feature of
 > the implicit address---one does not need to specify an address: it will
 > then be what is the default at the moment---makes the config a whole,
 > and failing on a line may define the default address with something
 > completely different from what was intended: what will be the result of
 > runnin login on the external interface instead of an internal one?
 > 
 > => a failure in the config now must discard the whole config.

I don't understand. You read the config, you check it, if it's bad you
complain to syslog and if it's good you install it. There's still no
reason to exit.

 > If the [-r] mode is asked for (r for "resilient"), in case of failure to
 > validate the config, inetd falls back to "/etc/inetd.fallback.conf" that
 > is also parses and, if checking successful, served. If even this
 > fallback fails, inetd(8) does not exit but serves the "no-op" config: it
 > does nothing simply waiting for the instruction to reload the config
 > ("the config" is always the one passed, explicitely or implicitely, on
 > the call).

That sounds way more complicated than necessary.

-- 
David A. Holland
dholland%netbsd.org@localhost