httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Hanging child process during MaxConnectionsPerChild exit (event, 2.4.11)
Date Tue, 20 Jan 2015 11:52:20 GMT
Isn't the TCP keepalive like 2hours or so?

> On Jan 20, 2015, at 2:45 AM, Ruediger Pluem <rpluem@apache.org> wrote:
> 
> 
> 
> On 01/19/2015 11:40 PM, Rainer Jung wrote:
>> I noticed a hanging child process on our ASF server aurora.
>> It currently uses 2.4.11 (plus the post tag commit) and event MPM.
>> Most processes exiting due to MaxConnectionsPerChild get cleaned up after some time
but this one doesn't. It now hangs
>> for more than an hour. I'll let it hang. In case anyone has a good question I can
answer with gdb let me know.
>> 
>> It shows a strange connection view in the server status table:
>> 
>> PID     Connections     Threads Async connections
>> total   accepting       busy    idle    writing keep-alive      closing
>> 93557   1       yes     0       0       0       0       0
>> 
>> So it has 1 connection, but 0s in all other columns.
>> 
>> The connection can be seen by lsof:
>> 
>> FD     TYPE             DEVICE   SIZE/OFF   NODE NAME
>> txt     VREG     183,3400335528   36497117 275235 /x1/www/archive.apache.org/dist/cordova/cordova-3.4.0-src.zip
>>  9u    PIPE 0xfffffe061ecfab60      16384        ->0xfffffe061ecfacb8
>> 10u    PIPE 0xfffffe061ecfacb8          0        ->0xfffffe061ecfab60
>> 24u  KQUEUE 0xfffffe033071be00                   count=0, state=0x2
>> 41u    IPv4 0xfffffe01316243d0        0t0    TCP 127.0.0.1:35849->127.0.0.1:8050
(CLOSE_WAIT)
>> 83u    IPv4 0xfffffe0255d08b70        0t0    TCP 127.0.0.1:52023->127.0.0.1:8050
(CLOSE_WAIT)
>> 108u    IPv4 0xfffffe09990eeb70        0t0    TCP 127.0.0.1:22532->127.0.0.1:8050
(CLOSE_WAIT)
>> 
>> This is the established connectioN:
>> 
>> 110u    IPv4 0xfffffe0255ab4b70        0t0    TCP 192.87.106.229:http->179.206.174.192:65496
(ESTABLISHED)
>> 
>> And this is likely the file being served on that connection:
>> 
>> 126r    VREG     183,3400335528   36497117 275235 /x1/www/archive.apache.org/dist/cordova/cordova-3.4.0-src.zip
>> 156u    IPv4 0xfffffe048d0ff3d0        0t0    TCP 127.0.0.1:26685->127.0.0.1:8050
(CLOSE_WAIT)
>> 229u    IPv4 0xfffffe0131d013d0        0t0    TCP 127.0.0.1:31538->127.0.0.1:8050
(CLOSE_WAIT)
>> 
>> netstat shows:
>> 
>> Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
>> tcp4       0  87650 192.87.106.229.80      179.206.174.192.65496 ESTABLISHED
>> 
>> so there's 87650 bytes in the send-q. Most lilely the client hans't acked what we
send.
> 
> Isn't it weird that the connection remains in this state for an hour? I would guess the
OS tries to resent whats in the
> buffer and if doesn't get  ACK'ed it would somehow timeout the TCP connection and assume
the peer is gone.
> 
> Regards
> 
> RĂ¼diger
> 


Mime
View raw message