GoWilkes

Well-Known Member
Sep 26, 2006
645
28
178
cPanel Access Level
Root Administrator
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?
 

GoWilkes

Well-Known Member
Sep 26, 2006
645
28
178
cPanel Access Level
Root Administrator
I found this:


Along with this:


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?
 

GoWilkes

Well-Known Member
Sep 26, 2006
645
28
178
cPanel Access Level
Root Administrator
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 :eek: 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
 

ITHKBO

Member
Jun 23, 2020
22
29
13
Netherlands
cPanel Access Level
Root Administrator
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 :eek: 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. :)
 
  • Like
Reactions: cPRex