Emptying /tmp

[GoWilkes]

My root /tmp directory is surprisingly large, taking up a lot of my server. There's one old file from 2018, then the next oldest starts at 11/24/2020.

There are also some directories in /tmp, like /tmp/systemd-private-[random]-ea-php74-php-fpm.service-[random]/tmp that du -h -d 1 /tmp/ can't seem to read. It's been running for 15 minutes and can't seem to get past it.

I understand that I can safely delete the files within those directories, but not the directories themselves?

Is there any reason that I can't delete all of the files in /tmp that are older than, say, a week, except for MySQL sock? The files (excluding subdirectories) are cumulatively about 4G!

If I'm right that I can safely delete all of the files, is there a built-in way to automate that so that it doesn't fill up my server again?

 

[dalem]

install tmpwatch & set a cron to clear the old files

 

[cPRex]

tmpwatch is likely the best idea - thanks @dalem

 

[GoWilkes]

I found this:

https://support.cpanel.net/hc/en-us/articles/360052677654-How-to-clean-your-tmp-directory-with-tmpwatch

Along with this:

tmpwatch(8) - Linux man page

tmpwatch recursively removes files which haven't been accessed for a given time. Normally, it's used to clean up directories which are used for temporary holding space such as /tmp.

linux.die.net

The cPanel article uses --all, which appears to delete EVERYTHING in /tmp that's over 1 week old. Including directories and the mysql.sock symlink.

Is that correct?

 

[cPRex]

I'm doing some testing on my end and I'll update you soon.

 

[cPRex]

I found on my system this is safe to run as the article describes as the mysql.sock file in /tmp gets recreated frequently on the system.

 

[GoWilkes]

I've had issues with MySQL before, and they're still not corrected. So any time I'm messing with something related to MySQL, my blood pressure goes up LOL

So before I run it, any advice on what I should do JUST in case it doesn't get recreated immediately?

It looks like a symlink, but FTP doesn't let me click on it to see where it takes me.

Or...

Would it be prudent to use --nosymlinks instead of --all? Eg,

tmpwatch --mtime --nosymlinks 168 /tmp

or to explicitly exclude mysql.sock? Eg,

tmpwatch --mtime --all --exclude=/tmp/mysql.sock 168 /tmp

 

[cPRex]

If for some reason that doesn't immediately reappear, this will work:

ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock

 

[ITHKBO]

I've had issues with MySQL before, and they're still not corrected. So any time I'm messing with something related to MySQL, my blood pressure goes up LOL

So before I run it, any advice on what I should do JUST in case it doesn't get recreated immediately?

It looks like a symlink, but FTP doesn't let me click on it to see where it takes me.

Or...

Would it be prudent to use --nosymlinks instead of --all? Eg,

tmpwatch --mtime --nosymlinks 168 /tmp

or to explicitly exclude mysql.sock? Eg,

tmpwatch --mtime --all --exclude=/tmp/mysql.sock 168 /tmp

While our situation might not be completely the same I can say that we have several production servers with a couple of hundred MySQL databases for 5+ years with tmpwatch on and never had any issue related to it nor had to exclude directories or modify MySQL configuration for it as far as our operational log shows.

That experience covers MySQL 5.6 , 5.7 and MariaDB 10.3
We are currently preparing for MySQL 8.0 upgrades but we do not expect any problems with it either.

So one more vote for the tmpwatch solution suggested by dalem.

 

[GoWilkes]

I just now ran tmpwatch via:

tmpwatch --mtime --all 168 /tmp

All is well, no issue