Apache locks session files for no reason

I keep running into stale, locked, (php) session files on my apache server which keep the threads from closing and thus eating away my server resources.

Its an Ubuntu box and having session_write_close(); in the automatically appended script doenst help. I keep ending up with locked session files which are local (memory disk) and with no other processes trying to access it...

I just dont know where to look anymore...

---

To clearify things a bit:

• we're running ubuntu stock apache2 (MPM prefork i believe) with standard PHP session handling
• the sessions are stored on a ramdrive so fsck-ing the thing wont do much ;)

The problem arises inconsistently and on different time intervals. But after looking at the open files (via lsof | grep sess_) i keep seeing apache2 threads holding on to those files.

apache2   28405 www-data   30uW     REG               0,18     38652    2737432 /data/ramdrive/sess_8f95700e5d2ed8daf2e2d12625ed7d53

Since i dont have the issue ATM i have no actual live data, but it looked something like this: doing an strace -p on the aforementioned id i would see something in the line of

F_LOCK(30, 

something... doing an ls -l /proc/[apache pid]/fd/30 (BTW everytime its always 30!) it would point to some session file

The actual file contained no weird stuff and looked pretty sane...

开发者_如何学Go

Does the fact that when it happened all FD's pointed to 30 (so it would end up being /proc/123123/fd/30 and /proc/123124/fd/30 etc) does that have to do with anything?

---

A very short post. We feel your pain, but...

stale, locked, (php) session files

This is odd. usually the system does no locking on session files. What eveidnece do you have that the threads are not closing because the session files are locked?

keep the threads from closing

Is this a threaded or pre-fork apache? While these days it should not make much difference, it would be helpful to know.

Are you using a custom session handler or the default?

Have you tried using a custom session handler which does not use files as the substrate (e.g. mysql, memcache). While this does not actually solve the problem, it might give an indication of what's going wrong.

Have you checked the state of the session files which have been created? Are new files created OK? What are the permissions? If you shutdown the webserver, delete the files manually then restart does the problem manifest immediately or only after a delay (latter may indicate a problem with garbage collection).

Anything of note in the syslog or httpd/error_log?

Have you fsck'd the filesystem lately?

While there may indeed be a problem with file-locking, I've never come across a problem like this.

---

Not really a solution, but i've now bypassed the problem by having a cron script reboot apache every 4 hours... this way atleast the problem wont have as much impact...