I was under the impression that “old” files in /tmp will be regularly deleted. However, it seems to me that /tmp will just grow as long as it wants to, and nothing will be deleted. Some people say it’s better to leave /tmp alone and delete its contents only if the disk is getting full.

My question is, is /tmp really designed to not take care of itself? What are the best practices?

  • 1
    normally /tmp gets cleaned after reboot, but this depends on the filesystem mounted there. What does df -h say? – etagenklo Apr 12 '13 at 20:14

To answer the questions:

  • Is /tmp supposed to be emptied automatically: Yes
  • Are we supposed to delete Files in /tmp regularly and manually: No, your system will take care of them.

If you may ask yourself:

  • Can I delete files from /tmp for whatever reason (need space, want to remove traces, etc.): It depends, read on.

Filesystem Hierarchy Standard (FHS) states:

The /tmp directory must be made available for programs that require temporary files.

Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.

/var/tmp/ has a similar purpose, but must not be deleted during reboot.

It is not guaranteed that /tmp/ or /var/tmp/ are cleaned up on a regular basis. This may depend on your distribution and settings, although most systems do some cleanup from time to time. See comment by mike.

If you need to to delete a file in /tmp, see first if the file is in use. You can do this easily with:

lsof /tmp/file_to_delete

If you have rights to do so, this will show the process holding the handle to that file, like process name, PID and type of the file. To show really all processes, prepend sudo or run as user root.

lsof +D /tmp

will show you all files in /tmp and directories below (+D) that are currently open. Of course you should not delete these files.

In fact when you delete a file that is still opened - if you have the rights to do so - it becomes inaccessible from the filesystem namespace, but it still exists for the processes that have an open file handle for it. After closing that handle, the file is not accessible for that process any more, and if no process has the file opened any more it is finally deleted. A process should not suppose that the file survives between subsequent open calls, but programmers are sloppy, and you never know. For that reason it's not that clever to delete files that are still in use by some programs.

| improve this answer | |
  • In general this is all excellent advice, esp the last paragraph. But whether a system does in fact clean up /tmp is dependant on that system. For instance, in openSUSE, it does not, unless you configure it to (from /etc/sysconfig, or via YaST). Also, users' personal ~/tmp (if they have one) is not automatically cleared. – mike Apr 13 '15 at 11:24
  • So it's still possible to delete files that processes have open? And this doesn't crash the program? Where does the file exist then? Can the program still interact with this "opened but concurrently deleted" file? Is there some way of making it difficult or impossible for rm to remove the file? Something like a file lock perhaps? – CMCDragonkai Apr 27 '15 at 10:44
  • Files are datasets in the file system that are made accessible in a hierarchical namespace, via a path and a file name. A file can have multiple names (hard links), and process can have an open handle for a file. If the file is not accessible, that is when it has no name and no open handle, it is deleted. Preventing a delete is beyond my expertise and IMO beyond the scope of this question. Try looking for "mandatary locking". – trapicki Apr 29 '15 at 8:05
  • [was a duplicate answer] – trapicki Apr 29 '15 at 8:35

I think this is OS varient dependent. I'd imagine that /tmp is typically cleared on reboot, and indeed it would not be safe for the system to clean itself up mid session as it won't know what files are active.

If you are brave you might want to throw a command into crontab which deletes files older then a certain age, but this might cause some issues if it deletes files still used. You might try a command (I have not tried it) like

find /tmp -type f -ctime +10 -exec rm {} +

Which will theoretically remove all files under /tmp older then 10 days.

| improve this answer | |
  • should probably add -r to that – Steven Penny Nov 21 '16 at 0:42
  • 1
    Absolutely DO NOT add -r to that - that will have the effect or removing files less then 10 days old where they exist in directories which were created more then 10 days ago. In-fact, the command should probably find / tmp -type f -ctime +10 -exec rm {} + to limit the search to files. (Using the find command will recurse subdirectories) – davidgo Nov 21 '16 at 1:34

The /tmp and /var/tmp directories are cleaned on a normal schedule. This may depend on your distro. On my CentOS system (a clone of RedHat) there is a cron job scheduled to run tmpwatch, a tmp dir cleaner, on a daily schedule. Files in /var/tmp are allowed to stick around a little longer than files in /tmp/. I've also seen scripts that prune /tmp (but explicitly not /var/tmp) on a reboot, knowing that there can be nothing holding that file open since all the processes are new.

So, yes, /tmp has maintenance from basic scripts. It still can fill up outside of those maintenance times. If you chose to clean things manually, best sysadmin practice is to be careful. Sysadmin lore talks about symlinks in /tmp pointing to necessary system files that were deleted when n00b sysadmins ran a simple find script.

| improve this answer | |
  • 2
    On Centos 7 and other RedHat-like version 7+ systems with systemd, the cleanup is configured in /usr/lib/tmpfiles.d/tmp.conf. This is invoked by systemd's target systemd-tmpfiles-clean.service. – shonky linux user Jul 13 '15 at 4:15

On CentOS there's a job in /etc/cron.daily called tmpwatch which will 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.

This is the /etc/cron.daily/tmpwatch script

#! /bin/sh
/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
        -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
        -X '/tmp/hsperfdata_*' 10d /tmp
/usr/sbin/tmpwatch "$flags" 30d /var/tmp
for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do
    if [ -d "$d" ]; then
        /usr/sbin/tmpwatch "$flags" -f 30d "$d"

/tmp directory contents get deleted only when system reboots, because running process may have accessing files from that directory.

| improve this answer | |

Distributions are different of course, but I'd expect temporary files to be managed automatically by the system out-of-the-box. They'd likely use either cron jobs or the systemd-tmpfiles-clean service. If you're worried about disk space, this is a useful command to take a look at how much space each root folder is taking:

du -hs /* | sort -h

To see if your system is using the systemd service for managing temporary files, you can just try:

systemctl status systemd-tmpfiles-clean

At the bottom you would see something like the following, which tells you when the service was last run:

systemd-tmpfiles-clean.service - Cleanup of Temporary Directories
   Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.service; static; vendor preset: disabled)
   Active: inactive (dead) since Wed 2018-07-18 15:43:36 IST; 18h ago
     Docs: man:tmpfiles.d(5)
  Process: 30495 ExecStart=/usr/bin/systemd-tmpfiles --clean (code=exited, status=0/SUCCESS)
 Main PID: 30495 (code=exited, status=0/SUCCESS)

Jul 18 15:43:36 host-name systemd[1]: Starting Cleanup of Temporary Directories...
Jul 18 15:43:36 host-name systemd[1]: Started Cleanup of Temporary Directories.

Note that this service will exit as soon as it's done with the clean-up. A timer service is responsible for regularly triggering it. You can check it with:

systemctl status systemd-tmpfiles-clean.timer

And you should expect something like the following:

systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
   Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled)
   Active: active (waiting) since Tue 2018-07-03 10:56:59 IST; 2 weeks 1 days ago
     Docs: man:tmpfiles.d(5)

Jul 03 10:56:59 host-name systemd[1]: Started Daily Cleanup of Temporary Directories.
Jul 03 10:56:59 host-name systemd[1]: Starting Daily Cleanup of Temporary Directories.

If you look again at the actual service responsible for cleaning the files, you'll see that all it does is run:

/usr/bin/systemd-tmpfiles --clean

So you could either run that command directly, or to do it properly, just do:

systemctl start systemd-tmpfiles-clean

Which will run the appropriate command for your system. However, you should be aware that this is not a "delete all temporary files now" command. There are several configuration files that control what actually gets deleted and when so that applications can individually configure their temporary files.

One place to look for generic handling of temporary files could be /usr/lib/tmpfiles.d/tmp.conf which might have the following relevant lines:

# Clear tmp directories separately, to make them easier to override
v /tmp 1777 root root 10d
v /var/tmp 1777 root root 30d

You could change those to a shorter time, if your system keeps running out of space, for example, to:

v /tmp 1777 root root 12h
v /var/tmp 1777 root root 1d

To be sure of what you're doing, do man tmpfiles.d to read the manual. Again, I have found the approach presented here to be relevant on a CentOS (RedHat based) and an Ubuntu system, but I don't know much about other distributions.

| improve this answer | |

You can remove the content from /tmp/; but the issue with doing so is that if you have a service that regularly writes to /tmp/ and you delete the files you may make the service crash or break until it's restarted.

| improve this answer | |

The FHS defines the /tmp directory as "temporary files (see also /var/tmp), often not preserved between system reboots", and /var/tmp as "temporary files to be preserved between reboots".

Nowadays, with /tmp being a RAM filesystem (tmpfs) by default (though optional) in many GNU/Linux distributions, /tmp is effectively non-persistent.

(Arguibly) applications should manage their temporary files accordingly, which in my opinion, includes deleting them when their use has ended, and not require administrators to schedule possible destructive deletions.

| improve this answer | |
  • A lot of programs could do a much better job of cleaning up files in /tmp when they are done with them, or when they exit, but there still exist a problem of files left in /tmp after an abnormal termination (crash) of a program. – Kevin Fegan Apr 13 '13 at 0:17

If you're running Debian (or a derivative like Ubuntu) you should look at your /etc/default/rcS file and adjust the TMPTIME environment variable. By definition what reside in /tmp has nothing to do here at next reboot.

I recommend

  • using the TMPTIME variable on a server
  • mount /tmp as tmpfs (in ram) on a desktop (for more speed)
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.