DO NOT REPLY [Bug 21322] New: - main worker process locks up and no longer accepts requests

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21322>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21322

main worker process locks up and no longer accepts requests

           Summary: main worker process locks up and no longer accepts
                    requests
           Product: Apache httpd-2.0
           Version: 2.0.46
          Platform: Sun
        OS/Version: Solaris
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: worker
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: glenn@apache.org


Once or twice a week we see the main apache process lock up and stop accepting
requests.  We have seen this on two different Sun E450's with dual CPU's running
Solaris 7.  Apache 2 is compiled with CC from Sun Workshop 5 and linked against
pthread.

We forced a core dump using gcore and this is what the backtrace reported:

current thread: t@0
=>[1] ___lwp_cond_wait(0xfee63f08, 0xfee63f18, 0xfee25c90, 0x0, 0x0,
0xfee25c88), at 0xfef19a94
  [2] __lwp_cond_timedwait(0xfee63f08, 0xfee63f18, 0x0, 0x3f046de1, 0x0, 0x0),
at 0xfef11560
  [3] _age(0xfee5c9ac, 0xfee5d72c, 0xfee5dfe8, 0xfee5e000, 0x3, 0xfee5c9ac), at
0xfee3a8dc
  [4] _lwp_start(0x6000, 0xffbef75c, 0xfee5d778, 0xfee5d760, 0xfee5c9ac,
0xffbef650), at 0xfee3be5c

I suspect this is happening when the main apache process worker MPM is forking
a child.  I did a quick man of fork and found the following which may help
explain what is going on:

  Fork-safety
     If fork1() is called in a Solaris thread program  or  fork()
     is  called  in  a   POSIX thread program, and the child does
     more than just  call  exec(),  there  is  a  possibility  of
     deadlocking  in the child. To ensure that the application is
     safe  with  respect  to  this  deadlock,   it   should   use
     pthread_atfork(3T).  Should there be any outstanding mutexes
     throughout  the  process,  the   application   should   call
     pthread_atfork(3T),  to  wait for and acquire those mutexes,
     prior to calling fork(). (See   attributes(5)  "MT-Level  of
     Libraries")

I checked the source for the worker MPM and it is not using pthread_atfork().

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org