Emptying /tmp
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?
-
install tmpwatch & set a cron to clear the old files 0 -
tmpwatch is likely the best idea - thanks @dalem 0 -
I'm doing some testing on my end and I'll update you soon. 0 -
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. 0 -
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 0 -
If for some reason that doesn't immediately reappear, this will work: ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock0 -
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. :)0 -
I just now ran tmpwatch via: tmpwatch --mtime --all 168 /tmp All is well, no issue :-D 0
Please sign in to leave a comment.
Comments
9 comments