Backup failed by tmp folder

Debian 9
multi php


I have this issue with an user account, He has only one website with prestashop.
the backup failed by tmp folder. In tmp folder I have many " sess_* " files. They crash the server because it was due to disk outage. I tried to delete those files but they are generate again.

How can I solve it ?


Those files are created by PHP and contain sessions from your user. You can’t stop them. Check

Or increase the size of your disk space…

1 Like

i Have those files…all similar


Yes, every user is 1 session…

1 Like


but the user is disconnected from yesterday. those files are hundreds

An example root cron task:
19 */1 * * * /usr/bin/find /tmp -name "sess_*" -mtime 1 -delete > /dev/null 2>&1


Note: ideally (for security reasons), session files should be saved in /home/user_name/tmp but then it becomes a bit more complex to automatically clean them.
19 */1 * * * /usr/bin/find /home/*/tmp -name "sess_*" -mtime 1 -delete > /dev/null 2>&1

(Unlike the first example, this one is untested - may need path expansion for the find statement)

Also, look into adjusting session expiration - IIRC there’s a PHP environment variable for that.

P.S. Thanks to @eris for the formatting tip below. :slight_smile:


Use four spaces before command or ` and place the text in between…


Thank a lot for your support.
I will test your code in cron command

You can run an initial test by manually executing the command. :rocket:
/usr/bin/find /tmp -name "sess_*" -mtime 2 -delete
Extended by a day, just to be safe. :wink:

1 Like

afaik hestia already adds a php-session-cleanup task to /etc/cron.daily
you normally don’t need to add an own one unless your prestashop install is configured to save them somewhere outside the regular user/php tmp dirs.

you could also check if prestashop itself has some proper garbage collection to cleanup it’s own mess.

sadly for some CMS or shop system every request to the page already creates a session, regardless if the visitor even does something. so if you got crawled a lot by bots you will end up with thousands of these session files.
if on top your box is on old spinning rust or doesn’t offer high IO this indeed leads to problems for everything that tries to stat/read all or archive these files, because that simply will take ages.

probably your system did not even crash but just was busy with those files?


there are many bots…any spambots other like normal bots (google, microsoft…)

many times the backup failed because it was due to disk outage. With the tmp folder empty…I have 53% disk usage. the session files are hundreds and hundreds.

[email protected]:/etc/cron.daily# cat php-session-cleanup
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 Hestia clear it after 7 days


probably check for a solution on prestashops end how to avoid the creation of these many files at all.

which folder ( full path ) do you mean when talking about the ‘tmp folder’?
what do you mean with ‘disk outage’ and 53% usage? disk space or IO usage? maybe you are running out of inodes?

without knowing details of the box you are running on sadly your informations are of not much help :wink:

the tmp folder is


53% disk space (not out inodes)

Sorry guys, I wasn’t aware of the php session clean ala WHM/cPanel. :expressionless:
I just remembered that I had a cron task that ran on a main server for a decade or more (probably until the ‘official’ cPanel one was introduced).

@falzo brings up valid points…
osCommerce and derivatives have a session save path and database storage option. There is also an option to check for spiders and not create a session. It’s been many years since I looked deeply into Prestashop to check for equivalent settings.

Note: my hosting specialises in e-commerce but Prestashop now has too many functional necessities that aren’t FOSS, IMHO. I’m an advocate for open source. :wink:


nothing to be sorry about. just the opposite, appreciate you trying to help out. sadly the attempts of hestia cleanup process seem to be not enough in this case so any additional ideas are appreciated I guess :wink: :+1:

1 Like

Now I added a cron to delete the folder tmp

find /home/%user%/tmp -type f -name ‘sess_*’ -delete

But I know it isn’t the solution right.

Can’t see what will parse your %user% variable, better to use an asterisk ( * ). Unless it runs as a user cron, rather than root, then it might parse the user. :wink: