hi,
is there an auto-magic cleanup for "temp_dir"?
if so, is there any way to fine tune this (e.g. after x days?)
if not, how about implementing such a maintenance job?
thanks, raoul
On 01.02.2011 10:45, Raoul Bhatia [IPAX] wrote:
is there an auto-magic cleanup for "temp_dir"? if so, is there any way to fine tune this (e.g. after x days?)
See rcmail_temp_gc() in main.inc
On 02/01/2011 11:09 AM, A.L.E.C wrote:
On 01.02.2011 10:45, Raoul Bhatia [IPAX] wrote:
is there an auto-magic cleanup for "temp_dir"? if so, is there any way to fine tune this (e.g. after x days?)
See rcmail_temp_gc() in main.inc
and where is the gc() function called from? i cannot find anything in relation to that.
looking at my sessions table, i can see that there are sessions dating back until 2 months (2011-11-30).
i somehow get the feeling, that gc is never actually done. running rc 0.5.1.
one quick thought: what about adding debug output to gc?
thanks, raoul
On 01.02.2011 13:30, Raoul Bhatia [IPAX] wrote:
and where is the gc() function called from? i cannot find anything in relation to that.
# grep rcmail_temp_gc program/include/* main.inc:function rcmail_temp_gc() rcmail.php: $this->session->register_gc_handler('rcmail_temp_gc');
looking at my sessions table, i can see that there are sessions dating back until 2 months (2011-11-30).
What's your session_lifetime setting? Temp gc is called in time of session gc execution.
On 02/01/2011 01:52 PM, A.L.E.C wrote:
On 01.02.2011 13:30, Raoul Bhatia [IPAX] wrote:
and where is the gc() function called from? i cannot find anything in relation to that.
# grep rcmail_temp_gc program/include/* main.inc:function rcmail_temp_gc() rcmail.php: $this->session->register_gc_handler('rcmail_temp_gc');
looking at my sessions table, i can see that there are sessions dating back until 2 months (2011-11-30).
What's your session_lifetime setting? Temp gc is called in time of session gc execution.
$rcmail_config['session_lifetime'] = 10;
if course i found register_gc_handler('rcmail_temp_gc'). this function sets:
$this->gc_handlers[] = $func_name;
there is only one other function in the program that accesses $this->gc_handlers[], namely program/include/rcube_session.php:
161: // garbage collecting function 162: public function gc($maxlifetime) 163: { 164: // just delete all expired sessions 165: $this->db->query( 166: sprintf("DELETE FROM %s WHERE changed < %s", 167: get_table_name('session'), $this->db->fromunixtime(time() - $maxlifetime))); 168: 169: foreach ($this->gc_handlers as $fct) 170: $fct(); 171: 172: return true; 173: }
where is this function "gc()" called from?
cheers, raoul
On Tue, Feb 1, 2011 at 1:52 PM, A.L.E.C alec@alec.pl wrote:
On 01.02.2011 13:30, Raoul Bhatia [IPAX] wrote:
and where is the gc() function called from? i cannot find anything in relation to that.
# grep rcmail_temp_gc program/include/* main.inc:function rcmail_temp_gc() rcmail.php: $this->session->register_gc_handler('rcmail_temp_gc');
looking at my sessions table, i can see that there are sessions dating back until 2 months (2011-11-30).
2010? ;-) Or do you email from the future?! ;-))
What's your session_lifetime setting? Temp gc is called in time of session gc execution.
In addition to what Alec said -- sessions are usually taken care of PHP itself. So e.g. you register a session handler and this is also where "gc" is registered and then PHP executes this based on session.gc_* settings in your php.ini.
On some Linux distros (like Debian/Ubuntu) that part is particulary broken as they disable PHP's garbage collector and assume sessions are in /tmp and run a cronjob on it instead of using the build in gargabe collector.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 02/01/2011 02:05 PM, till wrote:
In addition to what Alec said -- sessions are usually taken care of PHP itself. So e.g. you register a session handler and this is also where "gc" is registered and then PHP executes this based on session.gc_* settings in your php.ini.
On some Linux distros (like Debian/Ubuntu) that part is particulary broken as they disable PHP's garbage collector and assume sessions are in /tmp and run a cronjob on it instead of using the build in gargabe collector.
ah - this might be the issue then :) i'm running on debian and adapted my cronjobs to clean the correct session directory, as this is neither /tmp/ nor /var/lib/php5/.
my php.ini shows:
zend.enable_gc => On => On session.gc_divisor => 1000 => 1000 session.gc_maxlifetime => 1440 => 1440 session.gc_probability => 0 => 0
-> gc will runy with a probability of 0/1000 :)
what about rc using "ini_set('session.gc_probability', 1);"?
thanks, raoul
On Tue, Feb 1, 2011 at 2:17 PM, Raoul Bhatia [IPAX] r.bhatia@ipax.at wrote:
On 02/01/2011 02:05 PM, till wrote:
In addition to what Alec said -- sessions are usually taken care of PHP itself. So e.g. you register a session handler and this is also where "gc" is registered and then PHP executes this based on session.gc_* settings in your php.ini.
On some Linux distros (like Debian/Ubuntu) that part is particulary broken as they disable PHP's garbage collector and assume sessions are in /tmp and run a cronjob on it instead of using the build in gargabe collector.
ah - this might be the issue then :) i'm running on debian and adapted my cronjobs to clean the correct session directory, as this is neither /tmp/ nor /var/lib/php5/.
my php.ini shows:
zend.enable_gc => On => On session.gc_divisor => 1000 => 1000 session.gc_maxlifetime => 1440 => 1440 session.gc_probability => 0 => 0
-> gc will runy with a probability of 0/1000 :)
what about rc using "ini_set('session.gc_probability', 1);"?
IMHO, rather a case for the wiki.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
Raoul Bhatia [IPAX] wrote:
On 02/01/2011 02:05 PM, till wrote:
In addition to what Alec said -- sessions are usually taken care of PHP itself. So e.g. you register a session handler and this is also where "gc" is registered and then PHP executes this based on session.gc_* settings in your php.ini.
On some Linux distros (like Debian/Ubuntu) that part is particulary broken as they disable PHP's garbage collector and assume sessions are in /tmp and run a cronjob on it instead of using the build in gargabe collector.
ah - this might be the issue then :) i'm running on debian and adapted my cronjobs to clean the correct session directory, as this is neither /tmp/ nor /var/lib/php5/.
my php.ini shows:
zend.enable_gc => On => On session.gc_divisor => 1000 => 1000 session.gc_maxlifetime => 1440 => 1440 session.gc_probability => 0 => 0
-> gc will runy with a probability of 0/1000 :)
what about rc using "ini_set('session.gc_probability', 1);"?
thanks, raoul
You just need to enable .htaccess overrides for your RC install as this is enabled in the RC root .htaccess file:
... php_value session.gc_maxlifetime 21600 php_value session.gc_divisor 500 php_value session.gc_probability 1 ...
There is no need to mess about with the cron jobs etc. That may only break other PHP session stuff.
This is as documented in the Debian php.ini: ; 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. ; php scripts using their own session.save_path should make sure garbage ; collection is enabled by setting session.gc_probability
Chris _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 02/01/2011 02:43 PM, Chris Moules wrote:
You just need to enable .htaccess overrides for your RC install as this is enabled in the RC root .htaccess file:
nope. i'm using fastcgi and rc's .htaccess file does therefore not work ;)
however, i once tried pear's "htscanner". maybe this would fix this.
raoul
DI (FH) Raoul Bhatia M.Sc. email. r.bhatia@ipax.at Technischer Leiter
IPAX - Aloy Bhatia Hava OG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office@ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Tue, Feb 1, 2011 at 3:03 PM, Raoul Bhatia [IPAX] r.bhatia@ipax.at wrote:
On 02/01/2011 02:43 PM, Chris Moules wrote:
You just need to enable .htaccess overrides for your RC install as this is enabled in the RC root .htaccess file:
nope. i'm using fastcgi and rc's .htaccess file does therefore not work ;)
Stock php-(f)cgi lets you do all of the following:
php-cgi -c /path/to/custom/php.ini :-) php-cgi -d error_log=/home/foo/some.log
Till
however, i once tried pear's "htscanner". maybe this would fix this.
imho, .htaccess(-like) features carry a hefty performance penalty.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
hi till,
On 02/01/2011 03:10 PM, till wrote:
On Tue, Feb 1, 2011 at 3:03 PM, Raoul Bhatia [IPAX] r.bhatia@ipax.at wrote:
On 02/01/2011 02:43 PM, Chris Moules wrote:
You just need to enable .htaccess overrides for your RC install as this is enabled in the RC root .htaccess file:
nope. i'm using fastcgi and rc's .htaccess file does therefore not work ;)
Stock php-(f)cgi lets you do all of the following:
php-cgi -c /path/to/custom/php.ini :-) php-cgi -d error_log=/home/foo/some.log
i know that ;) still, .htaccess will not work there and i have to manually alter the phpini (instead of rc trying to set some non-critical parameters by itself)
so i enabled php gc and it works! thanks for the input. but why do we rely on php gc for doing the cleanup?
however, i once tried pear's "htscanner". maybe this would fix this.
imho, .htaccess(-like) features carry a hefty performance penalty.
thanks for the input. i'll take this into consideration.
cheers, raoul
On 02.02.2011 11:27, Raoul Bhatia [IPAX] wrote:
i know that ;) still, .htaccess will not work there and i have to manually alter the phpini (instead of rc trying to set some non-critical parameters by itself)
so i enabled php gc and it works! thanks for the input. but why do we rely on php gc for doing the cleanup?
I think we could detect session.gc_probability value and change it to 1 when it is set to 0. In case of Roundcube, disabling session gc is sensless.
Feel free to create a patch and open a ticket.
-
A.L.E.C -
Chris Moules -
Raoul Bhatia [IPAX] -
till