I keep encountering stale, locked, (php) session files on my small apache server which keep your threads from closing and therefore eating away my server assets.

Its an Ubuntu box and getting session_write_close() within the instantly appended script doenst help. I keep winding up with locked session files that are local (memory disk) with not one other processes attempting to can get on...

I simply have no idea where you can look any longer...


To clearify things a little:

  • we are running ubuntu stock apache2 (MPM prefork in my opinion) with standard PHP session handling
  • the periods are saved on the ramdrive so fsck-ing the one thing wont do much )

The issue arises inconsistently as well as on different time times. But after searching in the open files (via lsof | grep sess_) i keep seeing apache2 threads holding onto individuals files.

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

Since i have do not have the problem ATM i've no actual live data, however it looked something similar to this: doing an strace -p around the aforementioned id i'd see something within the type of

F_LOCK(30, 

something... doing an ls -l /proc/[apache pid]/fd/30 (BTW each time it's usually 30!) it might indicate some session file

The particular file contained no strange stuff and looked pretty sane...

Does the truth that if this happened all FD's pointed to 30 (therefore it would finish up being /proc/123123/fd/30 and /proc/123124/fd/30 etc) does which have related to anything?

A really short publish. We're feeling your discomfort, but...

stale, locked, (php) session files

This really is odd. usually system does no securing on session files. What eveidnece have you got the threads aren't closing because the session files are locked?

keep your threads from closing

Is a threaded or pre-fork apache? While nowadays it shouldn't make much difference, it might be useful to understand.

Are you currently utilizing a custom session handler or even the default?

Perhaps you have attempted utilizing a custom session handler which doesn't use files because the substrate (e.g. mysql, memcache). While this doesn't really solve the issue, it could give a sign of what is failing.

Perhaps you have checked the condition from the session files that have been produced? Are new files produced OK? Do you know the permissions? Should you shutdown the webserver, remove the files by hand then restart does the issue manifest immediately or only following a delay (latter may suggest an issue with garbage collection).

Anything of note within the syslog or httpd/error_log?

Perhaps you have fsck'd the filesystem recently?

While there might indeed be an issue with file-securing, I have never stumbled upon a problem such as this.

Not just a solution, but i have now side stepped the issue by getting a cron script reboot apache every 4 hrs... by doing this atleast the issue wont have just as much impact...