Just to add as a comment to people suggesting editing php.ini, what you
should actually do is edit /etc/php5/conf.d/local.ini, as that will
override any php.ini settings without causing configuration conflicts
when you next upgrade PHP (apt will warn you that the file you are using
differs from tha
Using cron is hacky here. It can be too slow (thus the disk fills up), or
usless (such as on a laptop with no sessions getting generated).
How about something more dynamic with php counting dirty sessions, and cleaning
them up synchronously at the end of a session? Let php handle this, when ph
I had a similar issue to Phil. A web server was generating PHP sessions
faster than they were being deleted by the cron job. This caused the
disk on which /var/lib/php5 was located to run out of inodes, and thence
to a loss of service.
It is caused by this upstream workaround, which is poor:
ht
The irony of the situation is that the latest Ubuntu PHP packages, in
Maverick and also Lucid I believe (but don't have a running version to
hand to verify) actually do contain the "original" php.net defaults for
garbage collection. So in fact BOTH the default PHP garbage collector
and the Debian c
I don't think anyone cares about the fastest or most efficient. But it
needs to be correct. That means that it should match the PHP
documentation at php.net. Currently, gc_maxlifetime is listed as
PHP_IN_ALL which means that a PHP file can modify the setting. This is
not true, above 1440.
I've
> Yet another reason to loose this cron job.
The reason why the Debian way of gc was introduced was security issue.
Phil, do you expect that standard installation of Debian PHP will work
out-of-the-box even on high load servers without any tweaks and
settings?
You are free to set the php in any
I found another issue with this cron job today.
One of our web servers was experiencing very high load, I assumed we had
high traffic and went to take a look at where the traffic was coming
from.
It wasn't website traffic at all.
We had so many PHP session files in the folder that the cron had f
** Changed in: php5 (Ubuntu)
Importance: Undecided => Low
** Changed in: php5 (Ubuntu)
Status: Incomplete => Confirmed
--
PHP session garbage collection
https://bugs.launchpad.net/bugs/316441
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
Related is a patch to mod_files.sh: http://bugs.php.net/bug.php?id=49175
** Bug watch added: bugs.php.net/ #49175
http://bugs.php.net/bug.php?id=49175
--
PHP session garbage collection
https://bugs.launchpad.net/bugs/316441
You received this bug notification because you are a member of Ubuntu
I'm adding to this report that the Ubuntu php.ini file has instructions
which are impossible to follow. The php.ini section on Debian session
handling refers to ext/session/mod_files.sh (a different program is for
Windows) which is not included in the Ubuntu PHP5 package. So Ubuntu
does not provi
If you edit /etc/cron.d/php5 you will have something like this:
# /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. Se
Will just modifying the php.ini file work or do I have to remove this
special cron job?
--
PHP session garbage collection
https://bugs.launchpad.net/bugs/316441
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
You're probably better off removing the Debian cron job and modifying
the php.ini yourself to your prefered settings (even if you revert them
back to the original PHP settings).
Unfortunately, it doesn't seam like anyone at Ubuntu is interested in
changing this away from the Debian modifications,
I think this needs to be looked into.
You cannot change the session.gc_maxlifetime in your php scripts using
ini_set("session.gc_maxlifetime", SOMEVALUE);
Everything says it was read correctly but the garbage collector reads
the session.gc_maxlifetime directly from the php.ini file and disregards
Well for starters I am not complaining, I'm making a suggestion.
So use of PHP functions and the default PHP distribution settings are
'non-standard'?
--
PHP session garbage collection
https://bugs.launchpad.net/bugs/316441
You received this bug notification because you are a member of Ubuntu
Bu
So you basically complain that you have to modify gc settings when you
are already modifying some other settings in non-standard way? Debian
way is properly documented, and you cannot expect everything to be
magickally working out of the box. Default install is ok, non-default
install has to be mod
In the [Session] section of php.ini there is the following:
; Define the probability that the 'garbage collection' process is started
; on every session initialization.
; The probability is calculated by using gc_probability/gc_divisor,
; e.g. 1/100 means there is a 1% chance that the GC process s
@Phil: Since you obviously looked closer at the matter, would you mind
easing up the bug confirmation process by giving some examples of what
works and what doesn't, which changes to php.ini you are refering to,
etc?
--
PHP session garbage collection
https://bugs.launchpad.net/bugs/316441
You rec
This is with latest Intrepid version.
--
PHP session garbage collection
https://bugs.launchpad.net/bugs/316441
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu
Which version are you using?
Thanks
chuck
** Changed in: php5 (Ubuntu)
Status: New => Incomplete
--
PHP session garbage collection
https://bugs.launchpad.net/bugs/316441
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu
20 matches
Mail list logo