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, 2013 at 20:14

8 Answers 8


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.

  • 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, 2015 at 11:24
  • 1
    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? Apr 27, 2015 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, 2015 at 8:05
  • [was a duplicate answer]
    – trapicki
    Apr 29, 2015 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.

  • should probably add -r to that
    – Zombo
    Nov 21, 2016 at 0:42
  • 2
    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, 2016 at 1:34
  • Hwo could one add lsof to check the file os ont being used?
    – snh_nl
    Sep 7, 2020 at 13:50
  • Probably worth also deleting empty directories after cleaning up the files.
    – dimo414
    Jan 16, 2022 at 20:07

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.

  • This is no longer true. (e.g. for RedHat/CentOS 7+). See this comment
    – rinogo
    Jan 7, 2021 at 17:18

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.


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.

  • 4
    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. Jul 13, 2015 at 4:15
  • Good point about systemd-tmpfiles-clean.service. But it doesn't sound correct to call it a target. It's a service invoked by a timer. In my case (CentOS 7) every day, and files older than 10 days are deleted. systemd-tmpfiles-clean.service is also present on Debian systems, but on servers I have access to (Debian 8, 9, 10) the age field is empty.
    – x-yuri
    Jun 29, 2021 at 22:40
  • In other words, it's there since year 2014/2012 (since day one?).
    – x-yuri
    Jun 29, 2021 at 22:42

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.


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.

  • 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. Apr 13, 2013 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)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .