Some * nix distributions, especially those based on Debian, the session.gc_maxlifetime
directive is ignored when set at run time.
This happens because such linux distributions disable the PHP garbage collector by setting session.gc_probability=0
.
To perform garbage collection, the Operating System itself creates a CRONJOB, usually running every 30 minutes. This CRONJOB does the garbage collection task. To identify the location and which sessions should be cleaned, the CRONJOB script reads "php.ini". Specifically, they search for the session.gc_maxlifetime
directive. Older ones search for session.gc_probability
.
On the internet you will find many posts indicating session.gc_probability=0
as a solution to avoid the error described in the question. However, this does not work on newer systems. Previously the script searched for this directive, but the current ones ignore and search for session.gc_maxlifetime
. This is why it is also common to see many users saying that it does not work with session.gc_probability=0
off.
For a more efficient solution, set the session.save_path
to a different location and disable the CHRONJOB automatically created by the OS.
In this case, if the chosen folder does not have a regular cleaning, garbage will accumulate. You should create your own script and run it on CRONJOB or enable the PHP collector session.gc_probability=1
itself.
To list the schedules of the user with whom you are logged in: crontab -l
. Log in as root and run this command to see the schedules. Then just disable the specific schedule: link
But in CentOS, the correct thing is that the session.gc_probability is 1. If
someone I know about, what can happen if I change
to 0 on a CentOS server?
Not necessarily. It can be set to zero. Then you should create your own collector, as explained above.