httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: is httpd a valid way to start Apache?
Date Fri, 17 May 2002 02:27:46 GMT
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,

> 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?

View raw message