httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 50261] graceful restart with multiple listeners using prefork MPM can result in hung processes
Date Fri, 12 Nov 2010 16:13:24 GMT

--- Comment #5 from Jeff Trawick <> 2010-11-12 11:13:20 EST ---
Charles, can you hit the problem with "AcceptMutex sysvsem" ?

I wonder if the stall of these two children in pthread_mutex_lock is caused by
the pthread mutex getting cleaned up in the parent when pconf is destroyed
while there are still users of the mutex.  I don't know what happens when the
parent munmaps the storage for the mutex or if that could be system dependent.

The following is just a quick hack to try to see if killing the pthread mutex
in the parent during this graceful restart scenario is what causes the children
to hang.  (It never deletes the old mutex.)

Charles, perhaps you could try to recreate with this patch and the default

Index: server/mpm/prefork/prefork.c
--- server/mpm/prefork/prefork.c    (revision 1034057)
+++ server/mpm/prefork/prefork.c    (working copy)
@@ -940,7 +940,7 @@

     rv = apr_proc_mutex_create(&accept_mutex, ap_lock_fname,
-                               ap_accept_lock_mech, _pconf);
+                               ap_accept_lock_mech, s->process->pool);
     if (rv != APR_SUCCESS) {
         ap_log_error(APLOG_MARK, APLOG_EMERG, rv, s,
                      "Couldn't create accept lock (%s) (%d)",

It isn't a permanent solution because it leaks pthread mutexes across graceful
restart, but it may be helpful for the investigation.

Configure bugmail:
------- 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