On Fri, Jun 02, 2023 at 01:21:15PM +0200, tlaro...@polynum.com 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 dholl...@netbsd.org