[wahern]

inetd, the "super server" from 4.3BSD, supported this in addition to handling the listening socket. For reasons I don't fully understand, inetd fell out of favor despite having been installed and running by default on pretty much every *BSD and Linux server for decades.

[whartung]

Couple things come to mind.

One, is that HTTP took over the role of a lot of simple servers, thus something like Apache and CGI-BIN was used in place of inetd.

Second, with the rise of interpreted languages (i.e. Perl et al), forking became more expensive. With binary programs, forking tends to be cheap (in a multi-use case) since the executable page are shared across processes. While the interpreter runtime itself is shared (being compiled), the actual script is not (having to be loaded for each instance).

The HTTP servers managed that better (through modules, FastCGI, etc.), so that space didn't really advance under the guise of inetd.

Make no mistake, an inetd service is "fast enough" for a wide array of use cases today, both compiled and interpreted, simply because the hardware is much better today. But, still, when folks think "ad hoc" service today, they're likely turning to HTTP today anyway.

[hibbelig]

I recall that inetd started a new instance of the demon for every incoming connection, and this caused lots of processes when lots of connections happened.

I don’t recall whether you could tell inetd not to do that.

[wahern]

inetd could pass the listening socket to the process. That was the `wait|nowait` field in /etc/inetd.conf. The typical config for TCP used with services like finger was `nowait`, which meant inetd would listen on a socket and spawn a new process for every incoming connection, without waiting for a previously spawned process to exit. But in `wait` mode it would spawn the process when it detected a connection, pass the listening socket (not connected socket) as fd 0, then wait for the server to exit before polling the listening socket again.

inetd was (remains?) a perfectly useful solution in this space. It just maybe needs some love to add some convenience features. Off the top of my head: 1) ability to split /etc/inetd.conf into, e.g., /etc/inetd.conf.d; 2) ability to trigger a restart of a specific service, rather than restarting the entirety of inetd.