httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brandon Long <>
Subject Re: Logging again
Date Sat, 27 May 1995 19:02:31 GMT
Last time, Randy Terbush uttered the following other thing:
> I could use some comments regarding the following. (especially related
> to the non-forker).
> One drawback that I am finding with the FIFO approach is that there
> is risk of the logged information being interlaced with other writes
> to the FIFO.  I sounds like as long as we are writing less than 512
> bytes we are OK (PIPE_BUF on NetBSD), but not something I am personally
> comfortable with. Comments?
> That brings me to what I think is probably a better solution...
> A socketpair.
> What happens in the non-forking model if the parent creates a socketpair
> to an http_logd process?  Will each child create the same socketpair
> to http_logd?   
> I picture this 'http_logd' reading in log.conf and creating the various
> FIFOs for the logcruncher processes.  For each file descriptor that
> the 'http_logd' opens to FIFOs, the configuration information would
> configure a logging structure for that pipe and start the specified
> logcruncher process reading from that FIFO.
> Is this an unusable solution for the non-forker?

Your parent process could handle the logging, in this case, since all
it does is sleep after forking all of the children.  It could select
on a socketpair from each (like NCSA does for the DONE signal) and 
receive the logging information from there.  The parent could then 
open a pipe for the logging, or log to a file, and it should ensure 
non overlapping (I think, it might have to internally buffer each
childs log info until it receives the end-of-transaction marker).


 Brandon Long   (N9WUC)     "I think, therefore, I am confused." -- RAW
 Computer Engineering   	Run Linux '95.	It's that Easy. 
 University of Illinois
		Don't worry, these aren't even my views.

View raw message