l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2009 Apr 10 17:23

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
[vox-tech] php session fun!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vox-tech] php session fun!

The app at work uses PHP.  I happened to notice a very large /tmp/phpsessions
directory.  I mean... the index is 74MB, let alone the files within.

So I discovered that yes: there's a cronjob that's supposed to be
cleaning these guys out (in /etc/cron.d/php5).  It uses "find -cmin" to
find all files older than X minutes, and "rm"s them.  However, it's doing
this only in /var/lib/php5, and not /tmp/phpsessions.

Digging around the conf file, I see that my predecessor
(I assume?) had changed the default session directory
to /tmp/phpsessions:

  ;session.save_path = /var/lib/php5
  session.save_path = /tmp/phpsessions

The comments in the php.ini file mention that garbage
collection can be done by PHP itself, but when I looked
at that section of the file, I saw:

  ; This is disabled in the Debian packages, due to the strict permissions
  ; on /var/lib/php5.  Instead of setting this here, see the cronjob at
  ; /etc/cron.d/php5, which uses the session.gc_maxlifetime setting below

So it seems that the cronjob, while checking the PHP ini files for
gc_maxlifetime, doesn't actually pay attention to WHERE they're stored

The odd thing is, recent session files (and not many of them, so cleanup
is happening as expected) also appear in /var/lib/php5.  So some are
getting stored there... I haven't figured out by whom, yet.
And I know that /tmp/phpsessions is actively being used, because its
timestamp always seems to be the current time.

I'm finding that /tmp/sessions is, in fact, so big that "ls", "ls -U"
and even "echo *" don't work.  Attempts at "ls" can't even be aborted
(^C) or suspended (^Z).

So I'm wondering... what's the safest way to get this directory cleaned up?
I'm thinking I need to create my own cronjob, based on the one that
comes with Debian, to deal with the files living in "/tmp/phpsessions".
(My initial thought was: "fix the existing cron job", but obviously it's
maintained by packages, so I don't want my work being blown away by an
upgrade, or confusing dpkg :) )

Thanks in advance!

Now back to my OTHER problems at hand,

Sent from my computer
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.