I was trying to log in to my wordpress site and it wouldn’t let me log in. I went into my CyberPanel dashboard to see what was up and saw that the disk usage was at 100%. It had been running closer to 80% most of the time, and something filled it up since the last time I checked. I ultimately discovered that there are files created for php sessions. Old files are supposed to get cleared out, but they weren’t. Here’s how I fixed it.
Seeing What Was Using Disk Space in Ubuntu
I logged in using Putty and installed a disk space usage program:
sudo apt install ncdu
And then you just type in ncdu and it starts the program. As there is no graphical user interface, it does take some navigating but ultimately I found that the directory that was taking up a lot of space was /var/lib/lsphp/session/
And then there folders for each version of php that I am using. I think most wordpress installations and plugins don’t use sessions, but in order to reduce server load caused by bots spamming my login pages, I installed the limit login plugin. It turns out that the plugin creates sessions to keep track of the IP addresses trying to log in. I’m guessing that one of my sites was getting hammered with bots and thus created a ton of sessions, ultimately filling up the drive. The odd thing was that it looked like files were there from when I first installed the plugin – like 5 months ago.
Cyberpanel – how to clear old session files
As best I can tell, Cyberpanel works by running a garbage collection script called through cron every 30 minutes, and any sessions more than a certain age get deleted. But for whatever reason, even that cron file was not working properly. Cyberpanel does not seem to use the typical garbage collection run through the php.ini variables of session.gc_probability and session.gc_divisor – CyberPanel has them both set to 0 by default. Changing them to the standard defaults of 1 and 100 did not seem to do anything as far as removing old session files.
So, the file that gets called by the cron file in the Cyberpanel setup is:
/usr/local/CyberCP/bin/cleansessions
The file that was there looked like:
#!/bin/bash
for version in $(ls /usr/local/lsws|grep lsphp); do echo ""; echo "PHP $version"; session_time=$(/usr/local/lsws/${version}/bin/php -i |grep -Ei 'session.gc_maxlifetime'| grep -Eo "[[:digit:]]+"|sort -u); find -O3 "/var/lib/lsphp/session/${version}" -ignore_readdir_race -depth -mindepth 1 -name 'sess_*' -type f -cmin "${session_time}" -delete; done
I didn’t try executing the script, but I suspect that for some reason it just wasn’t executing properly. It is supposed to get the setting from the php.ini file where session.gc_maxlifetime will be set to the number of seconds to keep session files. It is set to 14400 seconds, which would be 4 hours. However, the way the cleansessions script is written, it looks for files using -cmin which is in minutes. Even so, that would be 14400 minutes which would be 10 days. That wouldn’t explain why my session files were still there from months ago.
Anyway, the code that I found that fixes it to remove any files over 4 hours was:
#!/bin/bash
for version in $(ls /usr/local/lsws|grep lsphp); do echo ""; echo "PHP $version"; session_time=$(($(/usr/local/lsws/${version}/bin/php -i |grep -Ei 'session.gc_maxlifetime'| grep -Eo "[[:digit:]]+"|sort -u) / 60)); find -O3 "/var/lib/lsphp/session/${version}" -ignore_readdir_race -depth -mindepth 1 -name 'sess_*' -type f -cmin +"${session_time}" -delete; done
Which basically takes the original code, but then divides the time by 60, so you are back to 4 hours instead of 10 days. However, when I first uploaded the above script and try to run it manually by going to the directory and just typing
./cleansessions
which executes the script. But I got an error message:
-bash: ./cleansessions: /bin/bash^M: bad interpreter: No such file or directory
It turns out this is an error you get if you try to write the file on a windows based machine and then upload it to a linux based machine. I found a nice solution here to strip out the hidden characters that cause the problems with executing the script.
Run following command in terminal
sed -i -e 's/\r$//' cleansessions
Then try
./cleansessions
It should work.
And it worked! And now the cron is working correctly with clearing out any php session files over 4 hours old.