How is the /tmp directory cleaned up?
My temporary files never get written to the disk. They get written to a RAM disk. I did put tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 in /etc/fstab.
8 Answers 8
Note! This answer is outdated since at least ubuntu 14.04. See other answers for current situation and if they prove correct then upvote them furiously. Also post comment so I can put link here to current correct answer.
The cleaning of /tmp is done by the upstart script /etc/init/mounted-tmp.conf . The script is run by upstart everytime /tmp is mounted. Practically that means at every boot.
The script does roughly the following: if a file in /tmp is older than $TMPTIME days it will be deleted.
The default value of $TMPTIME is 0, which means every file and directory in /tmp gets deleted. $TMPTIME is an environment variable defined in /etc/default/rcS .
@Martin Schröder — the script exists on my system & it is a clean install of 14.04 and tmpreaper doesn’t exist!
I am using arch linux now so I cannot verify. Sorry. Please someone verify this and comment or edit my answer.
in ubuntu 16.04 tmpreaper is abandoned as un-secure please see: fossies.org/linux/tmpreaper/debian/README.security
No. In Ubuntu 16.04 it is simply superseded by a systemd mechanism. Read that document, and what you will actually find is an explanation of why the security analysis claiming insecurity is flawed.
The directory is cleared by default at every boot, because TMPTIME is 0 by default.
Here you can change the time in the following file:
TMPTIME says how frequent the tmp dir sould be cleared in days
Clearing at every boot is not ideal for a machine that is never rebooted, like a server. I’ve got over 500,000 files taking 5Gb space in my /tmp because my server has 378 days uptime. I’m reluctant to reboot it, simply because clearing those files on reboot make take hours.
While the /tmp folder is not a place to store files long-term, occasionally you want to keep things a little longer than the next time you reboot, which is the default on Ubuntu systems. I know a time or two I’ve downloaded something to /tmp during testing, rebooted after making changes and then lost the original data again. This can be changed if you’d like to keep your /tmp files a little bit longer.
Changing the /tmp Cleanup Frequency
The default setting that tells your system to clear /tmp at reboot is held in the /etc/default/rcS file. The value we’ll look at is TMPTIME .
The current value of TMPTIME=0 says delete files at reboot despite the age of the file. Changing this value to a different (positive) number will change the number of days a file can survive in /tmp .
This setting would allow files to stay in /tmp until they are a week old, and then delete them on the next reboot. A negative number ( TMPTIME=-1 ) tells the system to never delete anything in /tmp . This is probably not something you want, but is available.
good explanation. But in which script is the cleanup command? I have seen /etc/init/mounted-temp.conf , but it has the line start on mounted MOUNTPOINT=/tmp that make me think it is non applicable.
It’s also handy to keep files you don’t want to lose (rendered video frames) when your machine crashes, possibly due to OOM. A better solution would be to fix the problem, of course. 🙂
I think it would be better to keep such longer-term temp files in /var/tmp (as Gilles said). Then you can mount /tmp as tmpfs (as Arch Linux does).
I’m checking this on Ubuntu 16.10. I can certify that editing /etc/default/rcS has no effect at all anymore and the files in tmp are wiped out by reboot no matter what you put in that file. As others mention, tmpreaper is no longer used.
I think the right answer is that Ubuntu 16.10 has a new setup. There is a folder /etc/tmpfiles.d, documented in the man page «tmpfiles.d». In that folder, one should place a configuration file to control whether the /tmp is to be erased. This is what I am doing to stop reboots from erasing files in /tmp unless they are 20 days old:
#/etc/tmpfiles.d/tmp.conf d /tmp 1777 root root 20d Replace «20d» by «-» if you never want files deleted. This is my best effort, that man page is nearly impenetrable with detail.
The advantage of the new setup is that a file cleaner can still run even if the system is not rebooted (as in the case of an always on server). That’s a big plus, I think.
I found that you can preserve the original file permissions and owner by using hyphens: d /tmp/ — — — 20d
Also worth noting: you can test your configuration by running the cleaning job manually: systemctl start systemd-tmpfiles-clean
Creating /etc/tmpfiles.d/tmp.conf overrides /usr/lib/tmpfiles.d/tmp.conf causing the configuration for the other directories there to be lost if not copied (e.g., /var/tmp/systemd-private-%b-* ). See the source.
In Ubuntu 14.04 this is done by tmpreaper , which is called daily by cron (from /etc/cron.daily ). The program can be configured via /etc/default/rcS and /etc/tmpreaper.conf .
In a systemd Ubuntu (15.10 and newer), this is done by systemd, using the systemd-tmpfiles-clean service and timer:
$ systemctl cat systemd-tmpfiles-clean.service # /lib/systemd/system/systemd-tmpfiles-clean.service # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Cleanup of Temporary Directories Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8) DefaultDependencies=no Conflicts=shutdown.target After=local-fs.target time-sync.target Before=shutdown.target [Service] Type=oneshot ExecStart=/bin/systemd-tmpfiles --clean IOSchedulingClass=idle $ systemctl cat systemd-tmpfiles-clean.timer # /lib/systemd/system/systemd-tmpfiles-clean.timer # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Daily Cleanup of Temporary Directories Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8) [Timer] OnBootSec=15min OnUnitActiveSec=1d You can change the timer behaviour itself using systemctl edit systemd-tmpfiles-clean.timer , and using various systemd Timer configuration options (see man 5 systemd.timer ).
So systemd-tmpfiles-clean runs on shutdown, and once per day otherwise. The files it cleans can be extended using /etc/tmpfiles.d (mentioned in another answer).
It’s interesting to note that as default /etc/tmpfiles.d is empty. The file where the /tmp policy is defined is here:
# This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # See tmpfiles.d(5) for details # Clear tmp directories separately, to make them easier to override D /tmp 1777 root root - #q /var/tmp 1777 root root 30d So, as already noted, to override it, you can see the other answer about tmpfiles.d.
How to cleanup tmp folder safely on Linux
I use RAM for my tmpfs /tmp, 2GB, to be exact. Normally, this is enough but sometimes, processes create files in there and fail to cleanup after themselves. This can happen if they crash. I need to delete these orphaned tmp files or else future process will run out of space on /tmp. How can I safely garbage collect /tmp? Some people do it by checking last modification timestamp, but this approach is unsafe because there can be long-running processes that still need those files. A safer approach is to combine the last modification timestamp condition with the condition that no process has a file handle for the file. Is there a program/script/etc that embodies this approach or some other approach that is also safe? Incidentally, does Linux/Unix allow a mode of file opening with creation wherein the created file is deleted when the creating process terminates, even if it’s from a crash?
8 Answers 8
You might want to try something like that:
find /tmp -mtime +7 -and -not -exec fuser -s <> ‘;’ -and -exec echo <> ‘;’
find is used to find files that match certain criteria.
- -mtime +7 only selects files that are older than 7 days (you may use any other value)
- -exec fuser -s <> ‘;’ calls fuser in silent mode for every file that matches the oldness criteria. fuser returns 0 (=true) for every file that’s been accessed right now and 1 (= false) for the unaccessed ones. As we are only interested in the unaccessed ones, we put a -not in front of this -exec
- -exec echo <> ‘;’ just prints all file names matching the criteria. you might want use -exec rm <> ‘;’ instead here, but as this may delete some still-in-use files, I think it’s safer to do a simple echo first.
- edit: You might want to add something like -name ‘foo*.bar’ or -uid 123 to limit the effects of the cleanup to specific file patterns or user IDs to avoid accidental effects.
To the last point: Consider that there might be files that are only written once (e.g. at system boot) but read frequently (e.g. any X-session-cookie). Therefore I recommend adding some name checks to only affect files created by your faulty programs.
edit2: To your last question: A file won’t get deleted from disk until no process has an open handle to it (at least for native linux filesystems). The problem is that the directory entry is removed immediately which means that from the time you remove the file no new processes can open the file anymore (as there’s no filename attached to it).
edit3: But what if I wanted to automate the whole process?
As I said, there might be files that are written once and then read every once in a while (e.g. X session cookies, PID files, etc.). Those won’t be excluded by this little removal script (which is the reason why you might wanna do a test run with echo first before actually deleting files).
One way to implement a safe solution is to use atime .
atime stores the time each file was last accessed. But that file system option often is disabled because it has quite some performance impact (according to this blog somewhere in the 20-30% region). There’s relatime , but that one only writes the access time if mtime has changed, so this one won’t help us.
If you want to use atime , I’d recommend to have /tmp on a separate partition (ideally a ramdisk) so that the performance impact on the whole system isn’t too big.
Once atime is enabled, all you have to do is to replace the -mtime parameter in the above command line with -atime .
You might be able to remove the -not -exec fuser -s <> ‘;’ , but I’d keep it there just to be sure (in case applications keep files open for a long period of time).
But keep in mind to test the command using echo before you end up removing stuff your system still needs!