[php-maint] Bug#501313: Bug#501313: Bug#501313: Fixed in lenny?

Gokdeniz Karadag gokdenizk at gmail.com
Fri Oct 17 11:13:38 UTC 2008


Raphael Geissert demis ki::
> [Please do not send me a copy of the message, IOW: no To nor B/CC]
> 
> 2008/10/16 Gokdeniz Karadag <gokdenizk at gmail.com>:
> [...]
>> There is a problem in etch.
>>
>> In etch, I have changed the gc_probability in php.ini,
>> I gave a high probability/divisor ratio (about 1/10, also tried 1/1)
>> and restarted apache. Garbage collection never happened.
> 
> And what sessions path are you using? are you sure the process does
> actually have enough rights to delete the files? are you sure the max
> life time was reached?
> 

The sessions are stored in a database, and there is write access to database.
The webapp(Roundcube) did not have much users, there were 3000+ sessions in the
database. When garbage collection was moved to the webapp code my first login
initiated garbage collection and number fell to 16.

>> As soon as I copied those settings into the webapp's code with iniset,
>> garbage collection worked.
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267720
>> This states that gc_probability was compiled in as 0,
>> """
>> * Comment out session.gc_probability in the default php.ini, as we've
>>     now compiled in a default of 0, allowing the cronjob to do the
>>     garbage collection for us instead. (closes: #267720)
>> """
>>
>> Changing it back may allow the setting in php.ini work.
>>
> 
> The only change that was done here was to default to 0 in php itself
> (i.e. if gc_probability is not defined in php.ini it will default to
> 0/off).

I also guess so, but somehow the setting in php.ini does not get honored. (I
restarted apache, made sure no stale process exists.)

This bug was solved in roundcube by adding the ini_set call to the code, but
other people may have problems with other software.

- Gokdeniz





More information about the pkg-php-maint mailing list