Bug 180472

Summary: Graceful restart not so graceful ?
Product: [Fedora] Fedora Reporter: Mark McLoughlin <markmc>
Component: mod_pythonAssignee: Joe Orton <jorton>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-07-26 14:50:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mark McLoughlin 2006-02-08 12:27:38 UTC 
With a PSP page like this:

---
<html><body>
<%
import time
from mod_python import Session
for i in range (10):
    s = Session.Session (req)
    req.write ("%d %s</br>" % (i, s.id()))
    s.invalidate ()
    s.unlock ()
    time.sleep (0.5)
%>
</body></html>
---

If you do an "apachectl graceful" while the request is running you get an
exception like:

---
  File "/usr/lib/python2.4/site-packages/mod_python/Session.py", line 215, in lock
    _apache._global_lock(self._req.server, self._sid)

ValueError: Failed to acquire global mutex lock
---

If I enable debug spew around the global locks I see:

---
[Wed Feb 08 12:13:45 2006] [warn] _global_lock at index 3 from pid 19327
[Wed Feb 08 12:13:45 2006] [warn] _global_lock DONE at index 3 from pid 19327
[Wed Feb 08 12:13:45 2006] [warn] _global_lock at index 0 from pid 19327
[Wed Feb 08 12:13:45 2006] [warn] _global_lock DONE at index 0 from pid 19327
[Wed Feb 08 12:13:45 2006] [warn] _global_unlock at index 0 from pid 19327
[Wed Feb 08 12:13:45 2006] [warn] _global_unlock at index 3 from pid 19327
[Wed Feb 08 12:13:45 2006] [notice] Graceful restart requested, doing restart
[Wed Feb 08 12:13:45 2006] [warn] _global_lock at index 2 from pid 19327
[Wed Feb 08 12:13:45 2006] [warn] (22)Invalid argument: Failed to acquire global
mutex lock at index 2
---

I was also seeing this at one point too:

---
[warn] (43)Identifier removed: Failed to acquire global mutex lock at index 1
---

It seems pretty clear that a semaphore is getting destroyed before a child which
is using it has finished processing the request.
Comment 1 Joe Orton 2006-02-08 13:07:18 UTC 
That's how SysV sems work; you can't mark them to be deleted when the last user
exits.

mod_python could use semaphores which last the lifetime of the httpd parent, but
generally this isn't a good idea.  (if you lose track of them, they start leaking)

Better would be to just use file locking on the (on-disk?) session database and
not use a sysv sem at all.
Comment 2 Joe Orton 2007-07-26 14:50:07 UTC 
Closing this as "expected behaviour".