Re: does restarting apache reset php sessions?
Posted: Thu Feb 26, 2009 7:13 pm
what does it mean if I have no /var/spool/cron/crontabs folder?
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
Either your users don't have their individual crontabs, or those crontabs are located somewhere else on your system (but likely somewhere around /var/spool).kiwijones wrote:what does it mean if I have no /var/spool/cron/crontabs folder?
Yeah, those have to be scanned as well.VladSun wrote:...cron also reads /etc/crontab, which is in a slightly different format
(see crontab(5)). Additionally, cron reads the files in /etc/cron.d:
it treats the files in /etc/cron.d as in the same way as the
/etc/crontab file
Well, in fact every PHP installation (on Linux) modifies crontabs. So, while I agree that most of the clean up is done by the GC, there is still some cron jobs involved.inghamn wrote:Unless you're doing some special, cron also has nothing to do with it.
Not exactly - GC will not clean the old sessions on *every* session_start - that depends on session.gc_probability and session.gc_divisor:inghamn wrote:PHP is responsible for deleting session files. That's what the gc_ parameters in php.ini control. So, every time you call session_start(), PHP looks for session files on the hard drive (again, this is with file-based storage).
Code: Select all
session.gc_probability = 1
session.gc_divisor = 100I double checked my installations, and cannot find any PHP stuff in any of my crons. Am I missing something here? I did not think PHP added anything to cron.VladSun wrote:Well, in fact every PHP installation (on Linux) modifies crontabs. So, while I agree that most of the clean up is done by the GC, there is still some cron jobs involved.
Too true. I was having some troubles with this recently. Now I currently sandbox each application's session files in the bootstrapVladSun wrote:In fact, playing with session.gc_maxlifetime is a PITA when multiple web applications run on a single server, because the GC can not tell which file belongs to a session with shorter/longer lifetime.
Code: Select all
ini_set('session.save_path',APPLICATION_HOME.'/data/sessions');
ini_set('session.gc_maxlifetime',30*60);
session_start();
inghamn wrote:I double checked my installations, and cannot find any PHP stuff in any of my crons. Am I missing something here? I did not think PHP added anything to cron.VladSun wrote:Well, in fact every PHP installation (on Linux) modifies crontabs. So, while I agree that most of the clean up is done by the GC, there is still some cron jobs involved.
debian:~# cat /etc/cron.d/php5
# /etc/cron.d/php5: crontab fragment for php5
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php5/maxlifetime
# Look for and purge old sessions every 30 minutes
09,39 * * * * root [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm
Two different Debian servers.cat /etc/cron.d/php4
# /etc/cron.d/php4: crontab fragment for php4
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php4/maxlifetime
# Look for and purge old sessions every 30 minutes
09,39 * * * * root [ -d /var/lib/php4 ] && find /var/lib/php4/ -type f -cmin +$(/usr/lib/php4/maxlifetime) -print0 | xargs -r -0 rm