On Wed, May 15, 2002 at 12:49:46PM -0701, Jos Backus wrote: > What about moving into the other direction and moving the process management > portion into a separate set of tools so it can be used with other daemons > besides httpd?
I've pondered writing something like this, but then I also ponder the opposite. Why not build the supervise support into httpd itself. httpd would listen on a unix-domain socket or FIFO in the filesystem, and all graceful signals would be replaced with writes to this fifo. This eliminates the crufty signal layer between the supervise replacement and httpd, completely hides the difference between Unix and Windows (using the -k syntax) and potentially allows for more interesting status reporting from the command-line. Probably not viable for 2.0, though. > It would be great to have a BSD-licensed version of > something like djb's daemontools. I've (mostly) written replacements for supervise, setuidgid, and tcpserver. They use Single Unix APIs, haven't been ported to APR, and have no docs yet, but they are working for me. I imagine porting them to APR wouldn't be too painful, though they wouldn't remain the svelte 4-8kB binaries they are today. :) On Wed, May 15, 2002 at 07:15:47PM -0701, Jos Backus wrote: > Seriously, a decent process controller that would allow starting, stopping and > sending various signals to a command that runs as its child (i.e. duplicating > supervise's functionality) should not be too hard to implement. Nope, it wasn't. Assuming mine works, anyway. > It's the > fiddling with the pipes between two supervise's (the main one and the log/ > one) that seems tricky to me. I don't think this is a problem, because of the way Unix mangles the file descriptors. If you do something like: supervise /var/supervise/producer | supervise /var/supervise/consumer then, your shell will arrange the fd's so that stdout for producer points to a pipe to stdin for consumer. Then, when the supervise processes fork-exec their children, the kids inherit the 2 ends of the pipe, and just use them as if the pipe were set up just for them. If the producer dies, there's no problem, because the parent supervise still keeps an fd for that end of the pipe and passes it on to the next generation of the producer. Same goes for the consumer. It might be nice to use a technique like this to take the code for reliable piped logging out of httpd and make it more generally useful. > And I'd not sure how you'd wait() for the child > while still being able to select() on a name pipe in order to read control > messages sent by svc. In my supervise replacement, I use a technique picked up from the Awesome Might that is Dean (and which was used in some of the early MPMs). Create a pipe, and keep both ends of it. Create a signal handler for SIGCHLD that writes to the pipe. And, in the select() call you reference, wait on both the sigchld pipe (a.k.a. pipe_of_death) and the named fifo. Are people interested in this code?
