Hi everyone,
If you're using Debian Linux to host a SMF forum and are using database-driven sessions, I'd suggest to apply the below change
immediately. Due to how Debian manages sessions, if you're using database-driven sessions, the garbage collection (deletion of old sessions) is
not running and your smf_sessions table will grow to a massive size (mine got to 250,000 rows, consuming over 200 MB of space.)
In Load.php, find:
if (!empty($modSettings['databaseSession_enable']) && @version_compare(PHP_VERSION, '4.2.0') != -1)
session_set_save_handler('sessionOpen', 'sessionClose', 'sessionRead', 'sessionWrite', 'sessionDestroy', 'sessionGC');
elseif (@ini_get('session.gc_maxlifetime') <= 1440 && !empty($modSettings['databaseSession_lifetime']))
Replace with:
if (!empty($modSettings['databaseSession_enable']) && @version_compare(PHP_VERSION, '4.2.0') != -1)
{
session_set_save_handler('sessionOpen', 'sessionClose', 'sessionRead', 'sessionWrite', 'sessionDestroy', 'sessionGC');
ini_set('session.gc_probability', '1');
}
elseif (@ini_get('session.gc_maxlifetime') <= 1440 && !empty($modSettings['databaseSession_lifetime']))
Assuming that you're reading this, your sessions table is probably already rather full. The best thing is to empty it via a "TRUNCATE" (you may do so in phpMyAdmin, or
TRUNCATE TABLE smf_sessions via MySQL).
Technical explanation:
Because of Debian's security, /var/lib/php5 (the directory sessions are stored in) is unreadable by root users (essentially, CHMODded to 0733). Files have the permissions set normally, so PHP can still write files to the directory and read the files (providing it knows the file name, which would be the session ID), but no users can get a directory listing of the /var/lib/php5 directory. This is for additional security, I suppose - Trying to get a directory listing of the directory by whatever means will just give "Access Denied" messages, preventing local/hosted users from getting session data unless they know the session ID (on some other systems, getting a listing of /tmp/ will show all sessions, and then other users may steal these sessions).
Because of this, PHP's garbage collection won't work (because it can't get a list of all the files). Instead, Debian's PHP package comes with a cleanup cron job that runs every 30 minutes or so (I think) to remove the old files. This works fine for file-based sessions, but with database-based sessions, garbage collection needs to be implemented manually (or, like I've done here, the in-built PHP garbage collection needs to be turned on again).
Hope this helps
