Re: mod_cgid pipe leak
Aaron Bannert [EMAIL PROTECTED] writes: [assuming you meant to post this to dev@httpd instead] On Thu, Jan 24, 2002 at 12:19:57AM -0500, Bill Stoddard wrote: From STATUS * mod_cgid leaks pipe descriptors, apparently for every request. I would guess that this is due to recent apr_file_dup[2] changes. Is the leak in the cgid server process or the httpd process? in the cgid server process Could this be related to the other STATUS entry I just noticed? * Eliminate unnecessary creation of pipes in mod_cgid That is a long-standing problem. My feeling for the situation is that there is a long-standing API problem or mis-use of API by mod_cgid which leads to pipes being created unnecessarily there are long-standing bugs (duplicate cleanups?) that lead to invalid close calls (do strace on cgid daemon across a request to see several close(-1); some of what you see now may be related to the pipe leak but some has been there for a long time there is something new introduced at about the time of recent apr_file_dup[2] work that introduced the leak I'll try to follow up with an strace of the cgid daemon across a CGI... gotta rebuild (I always seem to have the wrong config for what I want to do next... maybe some cron jobs need to keep a couple of build flavors current :) ) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: mod_cgid pipe leak
Jeff Trawick [EMAIL PROTECTED] writes:
I'll try to follow up with an strace of the cgid daemon across a
CGI... gotta rebuild (I always seem to have the wrong config for
what I want to do next... maybe some cron jobs need to keep a couple
of build flavors current :) )
This is current HEAD on Linux (with some apr_pools.c code ifdef-ed
out so it woud compile... whats up with that?).
accept(6, {sin_family=AF_UNIX, path=@
020fwick/apacheinst/logs/cgisock}, [11]) = 7
read(7, \1\0\0\0, 4) = 4
read(7, \22\0\0\0, 4) = 4
read(7, \23\3\0\0, 4) = 4
read(7, /home/trawick/apacheinst/cgi-bin..., 787) = 787
read(7, \0\0\0\0, 4) = 4
pipe([10, 12]) = 0
fcntl(12, F_GETFL) = 0x1 (flags O_WRONLY)
fcntl(12, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
pipe([15, 17]) = 0
fcntl(15, F_GETFL) = 0 (flags O_RDONLY)
fcntl(15, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
pipe([18, 19]) = 0
fcntl(18, F_GETFL) = 0 (flags O_RDONLY)
fcntl(18, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
dup(2) = 20
dup(7) = 21
dup(7) = 22
close(7)= 0
fork() = 14788
close(21) = 0
close(22) = 0
close(20) = 0
close(-1) = -1 EBADF (Bad file
descriptor)
close(18) = 0
close(-1) = -1 EBADF (Bad file
descriptor)
close(15) = 0
close(12) = 0
close(-1) = -1 EBADF (Bad file
descriptor)
accept(6, 0xb968, [110])= ? ERESTARTSYS (To be
restarted)
--- SIGCHLD (Child exited) ---
accept(6,
After running a 3 CGI requests through, lsof shows this:
lt-httpd 14710 trawick0r CHR1,3 4101 /dev/null
lt-httpd 14710 trawick1w CHR1,3 4101 /dev/null
lt-httpd 14710 trawick2u REG3,5 62818 2050
/home/trawick/apacheinst/logs/error_log
lt-httpd 14710 trawick3u IPv4 824589TCP *:
(LISTEN)
lt-httpd 14710 trawick4u IPv4 824590TCP *:tproxy
(LISTEN)
lt-httpd 14710 trawick5u REG3,5 62818 2050
/home/trawick/apacheinst/logs/error_log
lt-httpd 14710 trawick6u unix 0xc06ef240 824604
/home/trawick/apacheinst/logs/cgisock
lt-httpd 14710 trawick8r FIFO0,0 824620 pipe
lt-httpd 14710 trawick9r FIFO0,0 824633 pipe
lt-httpd 14710 trawick 10r FIFO0,0 824641 pipe
lt-httpd 14710 trawick 11w FIFO0,0 824621 pipe
lt-httpd 14710 trawick 13w FIFO0,0 824622 pipe
lt-httpd 14710 trawick 14w FIFO0,0 824634 pipe
lt-httpd 14710 trawick 16w FIFO0,0 824635 pipe
lt-httpd 14710 trawick 17w FIFO0,0 824642 pipe
lt-httpd 14710 trawick 19w FIFO0,0 824643 pipe
So we lose 3 pipe descriptors per request.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: mod_cgid pipe leak
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick Sent: 24 January 2002 13:44 To: [EMAIL PROTECTED] Cc: Aaron Bannert; Bill Stoddard; [EMAIL PROTECTED] Subject: Re: mod_cgid pipe leak Jeff Trawick [EMAIL PROTECTED] writes: I'll try to follow up with an strace of the cgid daemon across a CGI... gotta rebuild (I always seem to have the wrong config for what I want to do next... maybe some cron jobs need to keep a couple of build flavors current :) ) This is current HEAD on Linux (with some apr_pools.c code ifdef-ed out so it woud compile... whats up with that?). Damn, damn, damn. Please tell me what you #ifdef-ed out, so I can fix it. Sander
RE: mod_cgid pipe leak
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick Sent: 24 January 2002 13:44 To: [EMAIL PROTECTED] Cc: Aaron Bannert; Bill Stoddard; [EMAIL PROTECTED] Subject: Re: mod_cgid pipe leak Jeff Trawick [EMAIL PROTECTED] writes: I'll try to follow up with an strace of the cgid daemon across a CGI... gotta rebuild (I always seem to have the wrong config for what I want to do next... maybe some cron jobs need to keep a couple of build flavors current :) ) This is current HEAD on Linux (with some apr_pools.c code ifdef-ed out so it woud compile... whats up with that?). Damn, damn, damn. Please tell me what you #ifdef-ed out, so I can fix it. Ok, I think I see the problem. Sorry about that. Sander
Re: mod_cgid pipe leak
[assuming you meant to post this to dev@httpd instead] Yep. On Thu, Jan 24, 2002 at 12:19:57AM -0500, Bill Stoddard wrote: From STATUS * mod_cgid leaks pipe descriptors, apparently for every request. I would guess that this is due to recent apr_file_dup[2] changes. Is the leak in the cgid server process or the httpd process? Could this be related to the other STATUS entry I just noticed? * Eliminate unnecessary creation of pipes in mod_cgid -aaron Perhaps. Thing is, mod_cgid was working correctly in the past and not leaking descriptors even with the overhead of creating the unneeded pipes. Jeff is probably right that the leak is related to the recent dup(2) changes. If we fixed the 'unnecessary pipe creation' problem, the leak might go away as well. I -think- the leak is in the cgid process rather than in httpd, just wanted to confirm I was looking in the right place... Bill
