httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <>
Subject piped logging bug
Date Fri, 03 Nov 2000 05:55:31 GMT
the test for write in the other_child code is flawed logic... the pipe
could be unwriteable just simply because it's full.  apache shouldn't nuke
the logger for that...

my suggestion is to just get rid of the writeable test.  if a server
blocks up because the logger is blocked it'll be obvious from the
scoreboard, and the fix will be to kill the logger manually.

as it is currently, this feature is more a liability than a feature :)

(i obviously never tested it well enough under load.)


---------- Forwarded message ----------
From: Paul Marquis <>
To: Linux Kernel Mailing List <>
Date: Thu, 02 Nov 2000 17:11:24 -0500
Subject: select() bug

I've uncovered a bug in select() when checking if it's okay to write
on a pipe.  It will report "false negatives" if there is any unread
data already on the pipe, even a single byte.  As soon as the pipe
gets flushed, select() does the right thing.

Normally, I wouldn't think this such a big deal, except that Apache
uses the writability of s pipe to determine if any of its children
that are log file handlers are dead.  If select() reports it can't
write immediately, Apache terminates and restarts the child process,
creating unnecessary load on the system.

The bug exists in the 2.2.x kernels up to and including 2.2.17 that
I've tried and I don't know it extends beyond pipes.  I've attached
sample code to demonstrate the problem, which works correctly on BSD
and Solaris.

Is this a know bug?

Paul Marquis

If it's tourist season, why can't we shoot them?

---------- Forwarded message ----------
Date: Thu, 2 Nov 2000 21:52:22 -0800 (PST)
From: dean gaudet <>
To: Alan Cox <>
Cc: Paul Marquis <>,
     Linux Kernel Mailing List <>
Subject: Re: select() bug
X-comment: visit for information regarding
    copyright and disclaimer.

> > Semantic issues aside, since Apache does the test I mentionned earlier
> > to determine child status and since it could be misled, should this
> > feature be turned off?
> Or made smarter yes

i'm scratching my head wondering what i was thinking when i wrote that
code.  the specific thing the parent wants to handle there is the case of
a stuck logger... you'd think i would have at least put some debouncing
logic in there.

(the parent is able to replace a logger without disturbing the children
because it keeps a copy of both halves of the logging pipes.)

an alternative would be to look for many children stuck in the logging
state (they make a note in the scoreboard before going into it).

paul -- if you want to just eliminate that feature (it'll still be able to
replace the logger if the logger exits) go into src/http_log.c,
piped_log_maintenance and comment out the OC_REASON_UNWRITEABLE.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

View raw message