Question: a few weeks ago, we setup a cronjob that wipes the entire contents of /tmp every Sunday at 5am. I wasn't really convinced that this is a good idea. Today we discovered that a certain task depended on an existing directory inside /tmp - the task was broken, and worse, it remained silence about why it failed. The question is:

Is it generally a bad idea to just wipe out /tmp?

Answer: 
It depends a bit on applications and distributions. It's typically safe to wipe /tmp on reboots. Wiping it on a running system is very likely to break applications. /tmp is not meant for permanent storage, and any application using it for such is serious broken, but applications can easily leave files in /tmp for months on a system that stays online. Which is why I am a bit suspicious about tmpwatch. 

In the end I only tend to look into how much is stored in /tmp when a server is running low on hard disk space. If there is plenty of HD space why bother?
According to [the FHS](http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES):

> 
> Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.
> 
> 
> Rationale
> 
> 
> IEEE standard P1003.2 (POSIX, part 2) makes requirements that are similar to the above section.
> 
> 
> Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.
> 
> 
> FHS added this recommendation on the basis of historical precedent and common practice, but did not make it a requirement because system administration is not within the scope of this standard.
> 
> 
> 

However, this is only a recommendation, and furthermore, it states only between invocations of a program -- which unless you're rebooting your server as well at 5am on Sunday, isn't happening. So, things like lockfiles, temp sockets, etc get deleted and cause problems.

As [MadHatter](https://serverfault.com/users/55514/madhatter) suggested, use `tmpwatch`.