Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
Date: Fri, 12 Nov 2010 11:13:24 -0500 (EST)
Message-Id: <201011121613.oACGDOnM011293@thor.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 50261] graceful restart with multiple listeners
 using prefork MPM can result in hung processes
In-Reply-To: <bug-50261-7868@https.issues.apache.org/bugzilla/>
References: <bug-50261-7868@https.issues.apache.org/bugzilla/>
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=50261

--- Comment #5 from Jeff Trawick <trawick@apache.org> 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
AcceptMutex?

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

     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: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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