httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 53579] httpd looping writing on a pipe and unresponsive (httpd <defunct>)
Date Fri, 16 Nov 2012 20:26:41 GMT

--- Comment #6 from george <> ---
After looking at the source code and doing some more testing, here are the

-This problem kicks in when the pipe-of-death becomes full (64 kbytes on a
Linux system). When this happens, then the httpd parent process is stuck in a
write() call, since the pod is blocking (?!) 
-The pipe-of-death is written to by the httpd parent process, one byte at a
time, in its main loop, as long as the number or httpd child processes exceeds
the "MaxSpareServers" setting in the httpd.conf file.
-The pipe-of death is read by the httpd child processes, in their main loop, as
long as there are HTTP requests sent to the server.
-If the httpd server is idle for a long time (5 days or so), then the child
processes are sleeping, either pending on a semaphore or in a system
epoll_wait() call with a very long timeout (100 days ?!).
-If the number of child processes exceeds the MaxSpareServers setting at the
time the httpd server becomes idle, then with only the httpd parent process
spinning, the pipe-of-death is constantly written to and no one is reading from
-When the parent httpd process writes to the pipe-of-death, it also sends a
"dummy" HTTP request to the child processes, making a TCP connection to the
system loopback interface on the httpd listener port.
-If for some reason the loopback interface and/or listener port are blocked by
the Linux firewall for example, then this "dummy" HTTP request fails and never
wakes the child processes up.
-When, after the pipe-of-death becomes full, the first external HTTP request
comes in, the httpd child processes wake up, process the requests, read the
pipe-of-death and go <defunct>.
-The parent httpd process cannot collect the <defunct> child processes, since
it it blocked in the write() system call.

In conclusion this problem is caused by a combination of:

internal httpd design:
-pipe-of-death blocks in write().
-child httpd epoll_wait() call does not timeout.

system problems:
-httpd listener port on the loopback interface is blocked.

You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message