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/1802: apache looses children
Date Fri, 13 Feb 1998 23:30:00 GMT
The following reply was made to PR general/1802; it has been noted by GNATS.

From: Dean Gaudet <dgaudet@arctic.org>
To: Gergely Madarasz <gorgo@caesar.elte.hu>
Cc: apbugs@hyperreal.org
Subject: Re: general/1802: apache looses children
Date: Fri, 13 Feb 1998 15:24:38 -0800 (PST)

 > >Environment:
 > debian/gnu linux, kernel version 2.0.32, glibc 2.0.5, 2.0.6, 2.0.7pre1
 
 Can you reproduce it with libc 5.x?  I don't trust glibc 2.0.x, and I've
 never had this problem on a libc 5.c system.
 
 > pipe([5, 6])                            = 0
 > fork()                                  = 9904
 > close(6)                                = 0
 > fstat(5, {st_mode=0, st_size=0, ...})   = 0
 > mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401a4000
 > read(5, "", 4096)                       = 0
 > --- SIGCHLD (Child exited) ---
 > close(5)                                = 0
 > wait4(9904, 0xbfffd440, 0, NULL)        = -1 ECHILD (No child processes)
 > 
 > actually these are all handled with the popen() and pclose() libc functions, 
 > called from the php module. php has nothing setup to handle SIGCHLD's, and as 
 > I see, apache doesn't either. I cannot quite understand what could cause this
 > a child exits and then wait4() reports there are no children. It looks as 
 > somehow SIGCHLD gets managed by SIG_IGN or something... afaik the child should 
 > be in <zombie> state until wait4()-ed, unless the SIGCHLD is handled by SIG_IGN
 
 This sounds like a broken libc.  Either that or they're interpreting the
 sigchld semantics using some variant of POSIX or Single Unix which I'm not
 understanding.  That trace looks completely bogus.  You're right, there is
 no SIGCHLD handler, so the wait4() is in error. 
 
 I'm still not in any position to change any of my machines to glibc 2.0.x,
 so I'll have a hard time debugging this.
 
 Any chance you could try to reproduce it with a small test program?  Then
 we can track down just who is at fault. 
 
 Dean
 

Mime
View raw message