Sorry if this is long-winded:

I have the same site running on two servers (server_old & server_new). It's a hand-rolled PHP & Ajax thing I made for managing my inventory and loaning out equipment to customers. It has a basic login system that is similar to the one featured on this website: How to Create a Secure Login Script in PHP and MYSQL. So it uses PHP session variables to check whether you're logged in and forces you to the login page if not. I didn't implement any kind of mechanism to kick you out after so many minutes or hours, at least not intentionally.

Server_old is running Linux Mint 17 with Apache 2.4.7 & PHP 5.5.9, and server_new is running RHEL 7 with Apache 2.4.6 & PHP 5.4.16.

I've looked in the httdp.conf & php.ini of both systems and I can't figure out why:

When I'm logged into the site on server_old, my login seems to only be good for about 20 minutes of inactivity. This makes sense if gc_maxlifetime is affecting it. When I try to access a page after sitting idle that long, it'll redirect me to the login page. This is good for security of course, so no complaints.

Then I migrated the site and DB to server_new and I've been logged in with no activity for what seems like several hours and it's still good. I know it's been more than 2, and I'm pretty sure more than 3 hours. I can still manually log out and the site won't let me past the login page until I log back in, so that part is working.

I just can't figure out why I get logged out of the site on Mint after a few minutes and on RHEL my PHP sessions apparently last forever. Both servers have:

  • session.cookie_lifetime = 0
  • session.cache_expire = 180 (180 minutes)
  • session.gc_maxlifetime = 1440 (1440 seconds / 24 minutes)

phpinfo() reports the same on both systems. However, on Mint the gc_probability is set to 0/1000 (essentially making it never collect the trash?) whereas on RHEL it's set to 1/1000. You'd think that never collecting the garbage and having cookie_lifetime = 0 would mean the session would last forever on Mint. But it's the opposite apparently.

Both Apache servers have been set with the same Timeout, KeepAlive, etc also.

Any ideas?

  • Debian-based distros perform garbage collection via. a cron job, which is why gc_probability is 0. cookie_lifetime = 0 means the session should disappear when you close the browser window. I'd suggest you view the cookies in your browser to see what expiry is being set. Also check that the clock on either servers isn't way out. Commented Jan 12, 2017 at 23:21
  • Ah, that makes sense. I checked the cookie under Chrome & Firefox and both just said it expires "at end of session". So to get my site on RHEL to log me out after a bit, I'll need to either implement a system on the website that checks the age of the session like shown here, or write a cron job that cleans house.
    – tannmatter
    Commented Jan 13, 2017 at 15:55

1 Answer 1


What is happening here is mainly due to the differences in garbage collection between different flavours of Linux. As mentioned above by @Tim Fountain garbage collection in debian-based flavours of linux perform garbage collection via a cron job. A check of PHP's documentation on sessions observes that the time set in gc_maxlifetime is the number of seconds after which data will be seen as garbage and potentially cleaned up. If garbage collection is not running on your server regularly then this won't be triggered and the data will remain.

The most reliable method to log a user out from a session after a certain amount of idle time is to add a session variable called something like lastAction which should be a unix timestamp using the time() function. Then each time a request is made you are first checking to see if the lastAction timestamp is older than a certain number of seconds (based on the max idle time you want), if it is then kill the session, run the logout code, and redirect the user to the login page, if it is less than the max number of seconds then reset the value of the lastAction session variable with the current unit timestamp and proceed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.