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:

4 Answers
4

It's not a bad idea to do something about stale old files in /tmp, but I'm not sure that nuking the contents is the best thing you could do.

My CentOS servers use something called tmpwatch, which runs daily and can be configured to remove only files that haven't been accessed in a certain period (30 days is a popular delay), or modified in a certain period; it can be told to leave directories alone unless they're empty, or not to touch directory files at all, or to exclude files used by a certain user (root is a popular choice).

This works well for me, and it offers enough hooks that you can tune it to do what you want. I'd recommend tmpwatch, or whatever your distro offers that's like that.

Extending MadHatters post a find statement using -mtime or -ctime could be combined with -exec rm {} \; to only remove files after a given period in days i.e. find /tmp -mtime +7 -exec rm {} \; however I'd be more inclined to suggest the task reliant on a directory existing in /tmp to be re-written, tmp exists to be temporary and removable, having a dependency for execution here is just nuts.
–
OneiroiNov 12 '10 at 15:45

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?

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.