PHP zombie sessions

[ctclibby]

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!

todh

[Bernhard Jaud]

ctclibby schrieb in etwa dies, Am 24.09.2006 18:58:

Hi All

Hi!

>
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!

todh

On my Debian-Server there is per default a cronjob that looks every 30
minutes for old sessions.

Cronjob:

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

/usr/lib/php4/maxlifetime:

#!/bin/sh -e

max=1440

for ini in /etc/php4/*/php.ini; do
cur=$(sed -n -e
's/^[[:space:]]*session.gc_max lifetime[[:space:]]*=[[:space:]]*\([0-9]\+\).*$/\1/p'
$ini 2>/dev/null
[ -z "$cur" ] && cur=0
[ "$cur" -gt "$max" ] && max=$cur
done

echo $(($max/60))

exit 0

HTH

--
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,
saying "END-OF-THE-WORLD-SWITCH!! DO NOT TOUCH!!!",
the paint wouldnt have time to dry.

-Terry Pratchett

[C.]

Bernhard Jaud wrote:

ctclibby schrieb in etwa dies, Am 24.09.2006 18:58:

Hi All

Hi!

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?

On my Debian-Server there is per default a cronjob that looks every 30
minutes for old sessions.

....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.

C.

[ctclibby]

MeAgain!

ctclibby wrote:

Hi All

Seem to be getting zombie sessions. /tmp/sess_[put your favorite 32

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
..subject.

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
that.

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!

[Bernhard Jaud]

C. schrieb in etwa dies, Am 25.09.2006 15:13:

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

But you KNOW to read posts before answering? ;-)

As i said this files are installed per default on my debian server. I
didnt't say that my sessions are terminated every 30 minutes, did i?

regards

Bernhard
--
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,
saying "END-OF-THE-WORLD-SWITCH!! DO NOT TOUCH!!!",
the paint wouldnt have time to dry.

-Terry Pratchett