www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: general/885: After a period of time (not found to coincide with server rehashes or any specific access), the server will read requests, but return no data (and close the connection). It will still respond to a server-status request though.
Date Fri, 14 Nov 1997 05:50:01 GMT
The following reply was made to PR general/885; it has been noted by GNATS.

From: Dean Gaudet <dgaudet@arctic.org>
To: Illuminatus Primus <vermont@gate.net>
Cc: apbugs@apache.org
Subject: Re: general/885: After a period of time (not found to coincide with server rehashes
or any specific access), the server will read requests, but return no data (and close the
connection).  It will still respond to a server-status request though.
Date: Thu, 13 Nov 1997 21:40:00 -0800 (PST)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.
   Send mail to mime@docserver.cac.washington.edu for more info.
 
 ---941424629-2105428548-879451192=:65950
 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
 Content-ID: <Pine.LNX.3.95dg3.971113213237.10796P@twinlark.arctic.org>
 
 
 
 On Thu, 13 Nov 1997, Illuminatus Primus wrote:
 
 > Yes, the problem was found to be that the logger process would die,
 > causing Apache to receive SIGPIPE whenever it would try to log something.
 > I noticed that on the list of changes for Apache 1.3, reliable piped logs
 > is amongst the changes.. thanks :)
 
 Yup but you might want to wait for 1.3b3 ... there's a bug in b2 with
 reliable piped logs. 
 
 > However, in the process of trying to hunt the bug down, I also noticed
 > that the ap_slack function can have undesireable behavior on 2.0.29
 > kernels.. I wrote a small program (testslack.c, attached), which basically
 > uses the ap_slack function that I copied out of Apache 1.2.1 to
 > continuously remap fds: 
 
 Oh interesting.  I'm looking at the kernel code right now ... there's no
 big change in this area between 2.0.29 and 2.1.62.  But it does definately
 look like a bug -- I just haven't convinced myself exactly how it's wrong. 
 Look at this from linux/fs/fcntl.c: 
 
         arg = find_next_zero_bit(&files->open_fds, NR_OPEN, arg);
 
 arg is the arg passed to F_DUPFD ... but find_next_zero_bit will scan from
 bit arg to bit arg + NR_OPEN - 1 ... which is wrong.
 
 It's probably a matter of changing the second parm there to NR_OPEN - arg
 ... but that might still be an off by 1.  I'm going to see if I can walk
 through the code by hand and figure out the right solution.
 
 > Fortunately, this small bug would/will only appear when 255-LOW_SLACK_LINE
 > fds have been allocated already, and it's relatively easy to work around
 > (just check to see if the new fd is the same as the old one)..
 
 That'd be an easy thing to include... I'm not convinced it's 100% correct
 yet though.
 
 Laters
 Dean
 
 ---941424629-2105428548-879451192=:65950--

Mime
View raw message