Re: inetd tests failing

[Brett Lymn <blymn%internode.on.net@localhost>]

On Tue, Mar 15, 2022 at 08:36:09AM -0400, Mouse wrote:
> 
> This doesn't even make sense unless (a) you keep a separate list for
> each service, (b) the daemon is expecting this (and thus signals its
> doneness by some means other than exiting), (c) you invent some
> interface for passing each new connection to an existing daemon
> process, and (d) you make all the daemons - including admin-provided
> legacy daemons - handle it.
> 

inetd is already keeping lists of what ports to listen on, what to exec
when something connects for each service so I don't see an extra list as
a big issue.  There doesn't need to be any concept of "doneness" here,
the daemon listens on stdin, writes on stdout, inetd sets up pipes to
each preforked child and just round robins the connections to the child
processes.  If the children cannot handle the load then the pipes will
fill, no problem.  The admin can increase the number of preforked
children if needed or maybe even allow inetd to bump the number of
chiidren on a pipe write stalling.

> > The apache http daemon has been doing this for a long time...
> 
> Apache's children - those children, at least - don't exec.  inetd
> children usually do, and the resulting processes have, in general, no
> way to be told "now go exec this other process instead, with this fd",
> so it doesn't make sense to me to put preforked children which are
> "done" back into a pool.
> 

Sure for apache it is just a fork but semantically starting a new
process is a fork followed by an exec.  To me it makes perfect sense for
something that is stateless not to bother tearing down a process - there
are plenty of things that don't carry state over from one request to the
next so why bother with the whole process tear down/start up when it is
not necessary?  To my mind it is almost like the people that insist on a
scheduled reboot "to clean things out" - if something is supposed to be
stateless but is keeping state then it is a bug that needs to be fixed.

> 
> Unless you are thinking the forked children should stop themselves
> instead of exiting and then *somehow* learn the new connection and exec
> path for the next thing inetd wants to use them for?  That's a lot more
> moving parts and a lot more fragility than just letting the existing
> child exit and forking a new one.
> 

They wait on stdin, they don't need to signal done.

-- 
Brett Lymn
--
Sent from my NetBSD device.

"We are were wolves",
"You mean werewolves?",
"No we were wolves, now we are something else entirely",
"Oh"