PHP Session files are not automatically being cleaned and PHP.ini file cannot be updated

[webspence]

I was unable to log into my WordPress admin due to PHP session files not being able to be created. After further investigation, the cause was that too many files were in the /tmp folder which blocked further files to be created in that directory (roughly 90,000 files). The first problem is that the session files are not being auto removed.

The second problem is that changes to the php.ini file do not take affect. I even removed the php.ini file and phpinfo() still reports that the original php.ini file is being loaded (even though it does not exist anymore) even after I reload lswsctrl and kill the lsphp processes.

The default session.save_path is set to "/tmp". Here is my session settings in my php.ini file (located at /usr/local/lsws/lsphp73/etc/php/7.3/litespeed/php.ini):

session.save_handler = files
session.use_strict_mode = 0
session.use_cookies = 1
session.use_only_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.cookie_samesite =
session.serialize_handler = php
session.gc_probability = 0
session.gc_divisor = 1000
session.gc_maxlifetime = 60
session.referer_check =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.sid_length = 26
session.trans_sid_tags = "a=href,area=href,frame=src,form="
session.sid_bits_per_character = 5

Any suggestions or comments are welcome!

 

[Pong]

It is a PHP question, not OLS question. Better split your different question into different thread.

For /tmp folder fill up issue, you can check what file filled up that folder.

For your php.ini issue, php detached mode should be restarted. "killall lsphp" should make it effective. If not, log a ticket we can check for you.

 

[svenms]

Yes it is a PHP question but, should not OLS installation modify the php.ini to have temp files removed with some periodicity?
Otherwise this problem will happen to every user with inode limitation.

 

[Cold-Egg]

session.gc_maxlifetime should works. If it's not, either switch the session folder, e.g. "tmp" to a bigger folder, or create a session clean-up script to handle cleaning up the session files every few minutes.

 

[philmck]

I just suffered a similar issue (3 years later) and noticed a problem with the above answer and with the default lsphp config. Most sites these days run on Ubuntu which is Debian based, and session.gc_probability is deliberately set to zero there because session files are saved in /var/lib/php/sessions (for security) and cleared with a cron job that calls usr/lib/php/sessionclean every 30 mins.

Unfortunately, lsphp seems to set the default location back to /tmp, which I think both exposes you to session stealing and prevents garbage collection working, eventually causing the server to fall over.

In case that's not complicated enough, Virtualmin tries to solve the problem in a different way by storing session files in a /tmp folder in each site's document root. I discovered a while ago that that also suffers from the same problem (lack of garbage collection of session files), except that it typically takes much longer to cause a problem because they're spread out over more folders.

There's very little documentation and discussions of this go back a decade or more so I might be wrong and other fixes might work. But as far as I can tell the problem still exists (which is why I'm here, my /tmp folder was full) but there's no problem either with security or overflowing folders if you accept the Ubuntu default settings. It's only when you mess with those without understanding how it works that you run into problems - and understanding is difficult because all the documentation seems to be missing, contradictory or out of date.

I've solved it by adding

session.save_path = "/var/lib/php/sessions"

to /usr/local/lsws/lsphp82/etc/php/8.2/litespeed/php.ini and restarted with

killall -9 lsphp

and it seems to have done the trick. I'll report back if the problem returns.

 

[philmck]

Update: I remembered that as far as Virtualmin is concerned, there was a fix added in 2020 that "will clean up sess_* files in each domain tmp dir that are older than 7 days by default" (https://archive.virtualmin.com/node/52635). However I concluded it's better to leave the Ubuntu behaviour alone.

 

[philmck]

Update update: I've been hit with this problem yet again (on a new server). It would be good to get the OLS defaults changed to something that works out of the box.

It's been brought to my attention that a good alternative is to store all session information in redis. It's faster and in particular avoids the "garbage collection" cycle that can slow the whole server significantly, especially with the default Ubuntu solution. I tried it and it works well, except it clashes with Nextcloud which already stores sessions that way. I've disabled it until I sort that out but it looks like the best long term solution. Of course, you have to have enough RAM to support it.