Linux/UNIX Server Setup Practices for /tmp

Based on what you all see out there what is a recommended configuration of /tmp on a server system and why. I've had discussions on these points over the years sometimes with basic disagreements.

The following are basically the questions I see. Some might suggest that these questeions be asked with several questions, however, I think it might be easier for administrators if this information was under one heading. I'm sure this will be informative.

Specifically for /tmp:

  1. Should ln -s /var/tmp /tmp?

  2. Should /tmp be preserved between reboots or not?

  3. Should /tmp be on a real disk area or allowed to be implemented basically on the SWAP area (or tmpfs)?

  4. Should /tmp be on a different disk from the / (root) disk?

  5. Would you place /tmp on a different disk controller from the / (root) disk?

  6. Any rules of thumb for the size of /tmp?

  7. How would you manage /tmp space while the system is up? Delete all files > certain age? Leave area alone until it reaches a %age of max?

  8. Should any procedural items be placed into effect to govern this area?


Specifically for /tmp:

  • Should ln -s /var/tmp /tmp?

In the case of a complete in-memory disk image (think "live boot CD") this might be acceptable, as every byte of RAM needs to be squeezed. Otherwise, unless you are hard-pressed for disk space, no. /var has its own peculiarities and mixing /tmp with /var/tmp may have unintended consequences when performing systems maintenance. It also adds an extra dependency in that /tmp must be mounted for /var/tmp to function properly; not everything needs /tmp and you may have a situation where you want to migrate it to a different partition or drive, but can't, because you don't want to unmount /var.

  • Should /tmp be preserved between reboots or not?

No. If you are relying on this as a consistent behavior then you will, sooner or later, encounter issues.

  • Should /tmp be on a real disk area or allowed to be implemented basically on the SWAP area (or tmpfs)?

When it's heavily used, this is a temptation - "we'll put /tmp into a RAM disk, it'll speed up access, and when the system reboots/shuts down, there's nothing to clean up". However, if you are thinking of implementing temp space as a RAM disk that will be swapped, then I would consider the ramifications of your system's swap space usage by other programs. If swap is there as a form of "emergency overflow" for when the system is in dire straights and needs it, the last thing you need is to have swap space consumed by a runaway process filling /tmp, consuming memory, causing pressure on the VM subsystem to swap to disk. Between swap activity, and the additional I/O streaming into the RAM disk (which in turn may cause additional page-ins to satisfy a seek() ) your system will quickly become I/O bound.

  • Should /tmp be on a different disk from the / (root) disk?

Preferably, yes, although it's not necessary. If you make heavy use of it, or have a constant workload that requires it, then definitely yes. Hypothetical example: a database that dumps temp files to /tmp would gain a slight speedup by introducing /tmp to a separate spindle (ie. drive).

  • Would you place /tmp on a different disk controller from the / (root) disk?

If you have a requirements for recoverability or speed, then it should be considered.

  • Any rules of thumb for the size of /tmp?

It should accomodate 2x your expected workload. By this, I mean that if you have local users regularly using this space, sooner or later someone will do something silly and attempt to fill it up. Having a slight overage will allow you to avoid strange "issues" with programs that stop because their temp files have filled up what space is left.

If this is a "common services" installation, where the server provides one or more network services, but does not host users, then this will probably be on the low side. If this is a multi-user installation, this will be on the high side (yes, there are still places that host actual users and not just their network services).

  • How would you manage /tmp space while the system is up? Delete all files > certain age? Leave area alone until it reaches a %age of max?

Look into the tmpwatch command, I think you'll find it suits this part of your question(s) nicely. The command simply deletes any files past a certain age in hours. Depending on how fast it fills up, you could do 30 days, 45 days, 90 days, etc.

  • Should any procedural items be placed into effect to govern this area?

I would recommend the following:

  1. All files are transitory, and are not guaranteed to survive a reboot.
  2. Stale files past %age will be removed nightly at midnight local time via a cron job that runs the tmpwatch command.

The rest is a matter of your specific needs.


An awful lot depends on the particular application load you're using. Some application servers (SunONE, old netscape stuff) write a few hundred to a few thousand files to /tmp - in that situation, you really don't want it to be a mounted ramdisk, and there's no reason to preserve it between reboots.

Servers are becoming less general and more special purpose- this type of question (and the similar "how do I partition my system" question) really depends on your loadout.

I did recently have one server that was rebooted for the first time after 4 years or so- it got stuck halfway through the boot deleting all the files in /tmp - there was so much cruft there that it took a good hour to clean it up. Definitely a good idea to clean it periodically if your box doesn't reboot very often.