/tmp didn't clear

1

So i was doing cleanup and saw I have 9gb worth of session files for months from a 400mb website.

I searched the forum and apparently there is an auto cleanup for tmp folder

# Look for and purge old sessions every 30 minutes

09,39 * * * * root [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi

Question is why do you think it fail?

Not sure if it’s failing now.

2

That cron job doesn’t fail because it doesn’t executes the session cleanup. As you are using systemd, the one doing the session clean-up is a systemd timer: phpsessionclean.timer that executes the service phpsessionclean.service

systemctl list-timers phpsessionclean
systemctl status phpsessionclean

Also, the php sessions should be by default in dir /var/lib/php/sessions/ not in /tmp/

Show the output of this command:

for i in $(v-list-sys-php plain);do echo "Checking PHP $i";"php${i}" -r 'echo ini_get("session.save_path") . "\n" . ini_get("session.gc_maxlifetime") . "\n";';echo;done
1 Like
3

Thank you for the reply.

Here is my output.

Checking PHP 5.6
/var/lib/php/sessions
1440

Checking PHP 7.0
/var/lib/php/sessions
1440

Checking PHP 7.1
/var/lib/php/sessions
1440

Checking PHP 7.2
/var/lib/php/sessions
1440

Checking PHP 7.3
/var/lib/php/sessions
1440

Checking PHP 7.4
/var/lib/php/sessions
1440

Checking PHP 8.0
/var/lib/php/sessions
1440

Checking PHP 8.1
/var/lib/php/sessions
1440

Checking PHP 8.2
/var/lib/php/sessions
1440

Checking PHP 8.3
/var/lib/php/sessions
1440

Sorry I just noticed the cron. It is indeed /usr/lib/php

If that is the case, then what are these in /home/xxx/tmp?

Got the same issue with this one

Other than having to delete them using

# Remove tmp session files over one day old
find /home/user/tmp -type f -name 'sess_*' -mtime +1 -delete

How to prevent this in the first place?

4

I thought you were talking about /tmp/ instead of /home/USER/tmp/. The default session path is /var/lib/php/sessions/, but Hestia creates custom variables and PHP settings to use /home/USER/tmp/ as upload dir, temporal dir, and session’s path when it creates the pool.

❯ cat /etc/php/8.3/fpm/pool.d/example.net.conf
; origin-src: deb/php-fpm/multiphp.tpl
;#=========================================================================#
;# Default Web Domain Template                                             #
;# DO NOT MODIFY THIS FILE! CHANGES WILL BE LOST WHEN REBUILDING DOMAINS   #
;# https://hestiacp.com/docs/server-administration/web-templates.html      #
;#=========================================================================#

[exampple.net]
listen = /run/php/php8.3-fpm-exampple.net.sock
listen.owner = USER
listen.group = www-data
listen.mode = 0660

user = USER
group = USER

pm = ondemand
pm.max_children = 8
pm.max_requests = 4000
pm.process_idle_timeout = 10s
pm.status_path = /status

php_admin_value[upload_tmp_dir] = /home/USER/tmp
php_admin_value[session.save_path] = /home/USER/tmp
php_admin_value[open_basedir] = /home/USER/.composer:/home/USER/web/exampple.net/public_html:/home/USER/web/exampple.net/private:/home/USER/web/exampple.net/public_shtml:/home/USER/tmp:/tmp:/var/www/html:/bin:/usr/bin:/usr/local/bin:/usr/share:/opt
php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f [email protected]

env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /home/USER/tmp
env[TMPDIR] = /home/USER/tmp
env[TEMP] = /home/USER/tmp

Hestia also adds a PHP session cleanup cron job that runs daily and removes sessions older than 7 days.

❯ cat /etc/cron.daily/php-session-cleanup
#!/bin/sh
find -O3 /home/*/tmp/ -ignore_readdir_race -depth -mindepth 1 -name 'sess_*' -type f -cmin '+10080' -delete > /dev/null 2>&1
find -O3 /usr/local/hestia/data/sessions/ -ignore_readdir_race -depth -mindepth 1 -name 'sess_*' -type f -cmin '+10080' -delete > /dev/null 2>&1

So, if you have that many GBs in your tmp directory, I suppose it’s because it’s also being used as an upload directory. To have 9 GB of session files, you would need more than 2 million of them.

5

Upload directory is within the public_html. Never something outside of public_html

As a matter of fact, it was indeed millions of sess files. Even rm -rf * gave me an error that it there were too many to delete.

Website is barely used. So I dont monitor it not until I was doing cleanup.

But I think I see the problem now.

The cleanup searches for sess_*

But the files generated has a name_sess* in it.

I find it unusual because

  1. None of my other websites generating with name_sess*.*
    Just the default sess*

  2. The name is actually the name of the system. Not the website. Not the domain. But the name of the program that I bought from codecanyon.

And after further investigation.

.env of the program has a line

app.sessionCookieName = 'name_session'

After commenting it out, the session files are now named

ci_session*

I guess this is a software specific problem. Not a hestia problem.

Edited the .env to
app.sessionCookieName = 'sess_'

And let’s see what happens

1 Like