php session recycling mechanism

Due to the working mechanism of PHP, it does not have a daemon thread to scan session information regularly and determine whether it is invalid. When a valid request occurs, PHP will decide whether to start a GC (Garbage Collector) based on the value of the global variable session.gc_probability/session.gc_divisor (which can also be modified through the php.ini or ini_set() function). By default, session.gc_probability = 1, session.gc_divisor = 100, which means there is a 1% probability that GC will be started.

The job of GC is to scan all session information, subtract the last modification time (modified date) of the session from the current time, and compare it with the session.gc_maxlifetime parameter. If the survival time has exceeded gc_maxlifetime, delete the session.

Then why does gc_maxlifetime become invalid?

By default, session information will be saved in the system's temporary file directory in the form of text files. Under Linux, this path is usually tmp, and under Windows it is usually C:WindowsTemp. When there are multiple PHP applications on the server, they will save their session files in the same directory. Similarly, these PHP applications will also start GC at a certain probability and scan all session files.

The problem is that when GC is working, it does not distinguish between sessions on different sites. For example, site A's gc_maxlifetime is set to 2 hours, and site B's gc_maxlifetime is set to the default 24 minutes. When the GC of site B starts, it will scan the public temporary file directory and delete all session files older than 24 minutes, regardless of whether they come from site A or B. In this way, the gc_maxlifetime setting of site A is useless.

Once you find the problem, it’s easy to solve it. Modify the session.save_path parameter, or use the session_save_path() function to point the directory where the session is saved to a dedicated directory. The gc_maxlifetime parameter works normally.

Another problem is that gc_maxlifetime can only guarantee the shortest time for the session to survive, and cannot be saved. After this time, the session information will be deleted immediately. Because GC is started based on probability and may not be started for a long period of time, a large number of sessions will still be valid after exceeding gc_maxlifetime. One way to solve this problem is to increase the probability of session.gc_probability/session.gc_divisor. If it is raised to 100%, this problem will be completely solved, but it will obviously have a serious impact on performance. Another method is to determine the lifetime of the current session in your code. If it exceeds gc_maxlifetime, clear the current session.

php session GC function is Garbage Collector. When this GC starts, it will clear those sessions that have "timed out". It works like this:

The user visits and logs in to the website. At this time, the background will call session_start to try to generate a session (if there is already a session, it is equivalent to a valid session request)

For each valid session like this Request, apache's php module will calculate the probability of starting GC based on the session-related global variable gc_probability/gc_divisor =>, and use this probability to decide whether GC should be started in this request. For example, the default value of session.gc_probability is 1, and the default value of session.gc_divisor is 100, then the probability of starting the "garbage collection" is 1%, which means that for every 100 requests, there will It is possible to clean up an expired session

If GC is started, GC will scan all session files under the path of the current session (session.save_path), and determine which sessions have expired based on another global variable session.gc_maxlifetime ("current The difference between "time" and "atime or mtime of the session file" is greater than gc_maxlifetime: expired), and delete these expired sessions

If you do not have any interactive operations for a long time after starting a session (for example, non-stop coding words, not submitted or saved as draft), then your session file saved in the background will not have the opportunity to be modified or accessed. After gc_maxlifetime (default value 1440 seconds = 24 minutes), it may be invalid. After being cleared, if you submit again after this, an error will be reported because the session has expired

It can be seen that gc_maxlifetime is set to 24 minutes, which is not enough for writing some articles. This is one reason. In addition, the default path of session.save_path is /tmp on Linux, and few programs will modify this setting. If there are multiple virtual hosts on this server, many session files with different session_names will be stored in the /tmp directory. What's bad is that PHP's GC does not distinguish session ownership. It will clean up all expired session files in this directory based on the gc_maxlifetime it obtains.

According to the above analysis, the solution is: UTBLOG adds a statement in the .htaccess file, expands the local value of session.gc_maxlifetime to 14400 (4 hours), and sets session.save_path to /tmp/utblog in the background. In this way, utblog's session file will not be interfered by other websites, and the expiration time of 4 hours, I think, should be enough anyway.

After testing it, everything is as I expected.

Also, of course it is also possible to directly change /etc/php.ini. If you do not have permission to change php.ini or apache's conf file, and .htaccess is prohibited, then directly modify the sessionmanager.class.php file of plog and add ini_alter("session.gc_maxlifetime", 14400) before the session_start line. Can. The plog structure is good, only this part calls session_start, so only this part needs to be modified. I've tested it locally and it works.

------------------------------------------------ --------------------------

session.gc_probability integer

session.gc_probability and session.gc_divisor are used together to manage gc (garbage collection Garbage collection) process startup probability. Default is 1. See session.gc_divisor for details.

session.gc_divisor integer

session.gc_divisor and session.gc_probability together define the probability of starting the gc (garbage collection garbage collection) process when each session is initialized. This probability is calculated using gc_probability/gc_divisor. For example 1/100 means there is a 1% probability of starting the gc process on each request. session.gc_divisor defaults to 100.

session.gc_maxlifetime integer

session.gc_maxlifetime specifies the number of seconds after which the data will be considered "garbage" and cleared.

Note:

If different scripts have different session.gc_maxlifetime values ​​but share the same place to store session data, the script with the smallest value will clean the data. In this case, use this directive together with session.save_path.

Note: If using the default file-based session handler, the file system must keep track of access time (atime). The Windows FAT file system does not work, so if you must use a FAT file system or another file system that cannot track atime, you will have to find another way to handle garbage collection of session data. Since PHP 4.2.3 mtime (modification time) has been used instead of atime. Therefore, it is no problem for file systems that cannot track atime.