PHP zombie sessions

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Hi All

Seem to be getting zombie sessions.  /tmp/sess_[put your favorite 32
hex characters here] exist and are owned by daemon.  I am guessing and
these could come from brower crashes, networks gone down ... etc ...
even from stuff that I haven't done properly.  So for the big question.

Can I run a cron job and delete these?  Or does PHP also store stuff in
another location and could cause me grief down the road?

Thanks in advance!


Re: PHP zombie sessions

ctclibby schrieb in etwa dies, Am 24.09.2006 18:58:
Quoted text here. Click to load it
Quoted text here. Click to load it
On my Debian-Server there is per default a cronjob that looks every 30  
minutes for old sessions.


09,39 * * * *     root   [ -d /var/lib/php4 ] && find /var/lib/php4/  
-type f -cmin +$(/usr/lib/php4/maxlifetime) -print0 | xargs -r -0 rm


#!/bin/sh -e


for ini in /etc/php4/*/php.ini; do
         cur=$(sed -n -e  
$ini 2>/dev/null
         [ -z "$cur" ] && cur=0
         [ "$cur" -gt "$max" ] && max=$cur

echo $(($max/60))

exit 0


Some humans would do anything to see if it is possible to do it.
If you would place a lager switch in some cave somewhere,
the paint wouldnt have time to dry.

-Terry Pratchett

Re: PHP zombie sessions

Bernhard Jaud wrote:
Quoted text here. Click to load it

...but you KNOW you should be finding out why they don't get deleted.

Why not bump up the gc_probability and see what impact it has.


Re: PHP zombie sessions

Kimmo Laine wrote:
Quoted text here. Click to load it

Unless next_page.php generates PHP, the script with this include will
only get HTML.

Quoted text here. Click to load it


    if (isset($_GET['foo'])) {
      echo '<?php echo $_GET[\'foo\']; ?>';
    } else {
      echo '<?php echo \'Not available\'; ?>';

File not found: (R)esume, (R)etry, (R)erun, (R)eturn, (R)eboot

Re: PHP zombie sessions


ctclibby wrote:
Quoted text here. Click to load it

Thought that you might want to know what I found out.  Of course,
things went sideways after I started figuring out what to do about the

User sessions are kept in a MySql database which lets them return to
where they are/were when something happens.  Well, found that if a user
just quit the logged in session, the database was not cleaned and would
stay there; as how would it know that the user has gone? I probably
knew this in the back of my mind, but didn't do anything about it until
now.   I created a cleaner to run at midnight(ish) looking for database
sessions that were older than 2 days.   This cleaner also removed the
zombie sessions from the filesystem also checking for the 2 day
thingie.  Now imagine my supprise while testing the cleaner that NONE
of the the file system session zombies were in the session database.
So I started looking elsewhere.

 I found that a session was started in an unrelated piece of code that
didn't have anything to do with user login.  This put a 0 filesize
session in /tmp.  Think that I got that fixed, time will tell.  I
started reading on the 'garbage cleanup' and will play around with

I guess that the end result is probably more of a 'why does it do that'
issue than anything and doesn't hamper the way php creates new
sessions.  How many combinations of 32 characters to generate the
session id?  Pretty slim chance of that happening twice.

have fun!

Site Timeline