January 24, 2017 4:01 PM, "Iznogoud" <iznogoud at nobelware.com> wrote: > (This message wil lbe of no help.) > > Ah, that is the "moving target" problem I was talking about. In the old days, > the "inetd" spawned processes as per-service daemons once it got a trigger > (connection) to a port. It worked well in the 90s, including on my... Amiga 500. > That is essentially what the OP is looking for, and what a sad way to do it > with the directory structure. > > Progress is not always... forward. You are correct: the message was not of help. inetd was(is?) a special purpose daemonizer, specifically to handle TCP and UDP applications. It handled the listener that spawned a child process for each incoming request. It is a daemonizer, but only for that specific case. The listener code has migrated to other apps these days. I am looking for generic daemonizers. The directory structure is not "a sad way". It is a very elegant configuration method. Instead of editing a configuration file with a text editor, and then sending a signal to the process (a la inetd), you place a "configuration" by soft-linking a config directory into the daemontools/runit service directory. This generates an event (or polling occurs) and the new service is automatically started. It is much easier to do automatically, especially for tools like ansible or chef. My beef is with the arcane requirements to remove a service in daemontools. I have to look up the sequence every time. Runit does not have this arcane requirement, just "rm" the symlink and the service goes away. (Again, note, no manual restarting of the daemon, nor complex editing of configuration files). John