Ticket #604 (defect)
Opened 2 years ago
Last modified 2 years ago
Hanging server
Status: closed (fixed)
| Reported by: | guest | Assigned to: | fumanchu |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.0 |
| Component: | CherryPy code | Keywords: | session tool |
| Cc: |
Robert I'm still having the problem where the server hangs while acquiring the session lock, I dug further and it's because of dangling lock files, it happens when my code has errors or exceptions somewhere, I think(I'm a trial and error debug kind of guy).
I tweaked lib/sessions.py on line 264 to view the exception:
except OSError, e:
print e
and this is what I get (repeated every 0.1 second, it loops forever (or until the lock file is removed)):
OS ERROR [Errno 17] File exists: 'session/session-141b87e22dd08c3f8a6d190a38f6f54ab891612c.lock'
I guess the session tool should clear stale lock files on startup, shouldn't it?
As I've already said, I'm not really familiar with locks, I know how they work and everything but I can't really have a say in this.
This problem affects the browser holding the session id. I have to kill -9 the cherrypy process because it doesn't stop on control+c.
Change History
11/20/06 22:58:48: Modified by Sheco
11/22/06 17:30:00: Modified by fumanchu
- status changed from new to assigned.
Hm. I've worked hard to make sure those lock files are guaranteed to be closed; it's possible that "kill -9" is the culprit. I don't want to "clear stale lock files on startup", because that would deny multiple processes running the same app and sharing the session data dir (which has been seen in the wild).
My best recommendation at this point would be to move to using a NamedTemporaryFile? for the lockfile; which (at least on my Win2k box) disappears when the owner process is forcibly killed.
Thoughts?
11/23/06 15:42:12: Modified by Sheco
Now that you mention it, it must be because of the kill -9, sometimes when the service doesn't want to auto-reload and it doesn't want to shut down cleanly I kill it on the spot. I've also been having that issue, I'm tracking it, I might create another ticket later on.
Back to this ticket, I don't think it is important to follow this up, since it's probably because of a kill -9. The easiest solution would be just a little warning on startup if there are lock files in the session directory. It'll be up to the user to decide what to do about them, unless of course you do want to fix this rare situation with the NamedTemporaryFile?.
11/27/06 16:35:35: Modified by fumanchu
- status changed from assigned to closed.
- resolution set to fixed.
Warning added in [1452].
11/28/06 16:26:12: Modified by fumanchu
Warning fixed in [1454].
Just for the record, I submitted the ticket.