Bug 180472 - Graceful restart not so graceful ?
Graceful restart not so graceful ?
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: mod_python (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-08 07:27 EST by Mark McLoughlin
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-26 10:50:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mark McLoughlin 2006-02-08 07:27:38 EST
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 08:07:18 EST
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 10:50:07 EDT
Closing this as "expected behaviour".

Note You need to log in before you can comment on or make changes to this bug.