CyberPanel not deleting any of the old session files

Support and Discussion General Discussion
1

Hello,

Today I found one of my CP servers to be partially down because it hit the inodes limit - PHP session files filled up php/sessions/ and /tmp/ folders and after deleting some files, I found out that they were never being deleted and were piling up from day 1.

After my investigation, I found that:

  1. CyberPanel enforces session.gc_probability as 0 in PHP configs which stops trash collector from working.

  2. CyberPanel has a cronjob to delete older session files, but multiple forum posts dated around 2022 stated that the bash command is wrong and has to be manually changed for it to work. After looking into it, the bash doesn’t exist at all in my instance, it is listed in crontab, but the file doesn’t even exist:

root@srv1:~# crontab -l | grep cleansessions
09,39 * * * * /usr/local/CyberCP/bin/cleansessions >/dev/null 2>&1

root@srv1:~# ls -lah /usr/local/CyberCP/bin/cleansessions
ls: cannot access ‘/usr/local/CyberCP/bin/cleansessions’: No such file or directory

I have 3 different VPS servers and this file doesn’t exist in any of them.

Version: 2.3.8

I wasn’t able to find any related posts from the recent years, so I’d like the CP developers to confirm what is the situation and the best approach here?:

  1. Why is CyberPanel not handling this through neither of these approaches? It’s a ticking time bomb for the inodes to be hit for almost all websites;

  2. Will session.gc_probability even work when enabled, or is it hardcoded in CyberPanel to disable it either way?
    2.1. If not disabled globally, what is the better approach to fix this issue (besides moving sessions saving to redis/memcached) - to just enable session.gc_probability or to create the bash of cleansessions and fix it?

2

Ubuntu 22.04 on all servers;

Current Version:  2.3
Build:  8
Current Commit:  15c4062cb085a8f213fa8be0de3cb359b492733c
Latest Version:  2.4
Latest Build:  4
Latest Commit:  41a9d84974e09e741433f77b8f11b6103ab67be8


Current Version:  2.3
Build:  8
Current Commit:  aecb42026ffaf7972bdd5e8b45cbb1878d7f97bd
Latest Version:  2.4
Latest Build:  4
Latest Commit:  41a9d84974e09e741433f77b8f11b6103ab67be8
3

Fixed by creating the /usr/local/CyberCP/bin/cleansessions file and using this custom bash:

#!/bin/bash
for version in $(ls /usr/local/lsws | grep lsphp); do PHPBIN="/usr/local/lsws/${version}/bin/php"; [ -x "$PHPBIN" ] || continue; echo ""; echo "PHP $version"; gc_maxlifetime=$("$PHPBIN" -i | grep -Ei 'session.gc_maxlifetime' | grep -Eo "[[:digit:]]+" | sort -un | head -1); if [[ -z "$gc_maxlifetime" || "$gc_maxlifetime" -eq 0 ]]; then echo "  Skipping: could not determine session.gc_maxlifetime"; continue; fi; session_time=$(( gc_maxlifetime / 60 )); find -O3 "/var/lib/lsphp/session/${version}" -ignore_readdir_race -depth -mindepth 1 -name 'sess_*' -type f -cmin +"${session_time}" -delete; done