Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I was under the impression that /tmp will regularly delete "old" files. Seems to me that /tmp will just grow as long as it wants to and won't delete anything. Some people say it's betetr to just leave /tmp alone and just delete if disk is getting full.

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

share|improve this question
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

7 Answers 7

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.

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 simmilar purpose, but must not be deleted during reboot.

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 a 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 survive 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.

share|improve this answer

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.

share|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.

share|improve this answer

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 -ctime +10 -exec rm {} +

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

share|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.

share|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)
share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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