Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
add comment

6 Answers

up vote 13 down vote accepted

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.

share|improve this answer
1  
Very good and comprehensive answer. Another reason you might want /tmp to be on its own partition is when you have user logins on the system. Since every user can write to /tmp, it is possible for a user to fill up the partition that /tmp resides on, causing problems for other programs. –  8jean Jun 5 '09 at 14:58
add comment

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.

share|improve this answer
add comment

From experience I recommend not mixing your /var/tmp and /tmp directories.

The reason being /var is (hopefully) where all your log, cache and service data (e.g. databases) will reside. It is generally a good idea to place /var on a separate partition so if a significant data event (e.g. lots of logging or database writes) occurs your root and /tmp partitions will still have free space to reliably operate.

For example I have literally just returned from a site where this practice was not followed (i.e. everything was on one partition) and as a result of log build up the entire system was brought to its knees. If a sane partitioning layout had been followed, the /var partition would have run out of space, but the server would have stayed responsive.

share|improve this answer
add comment

Only answering some points...

I would put /tmp on a different partition than /, just so that I could mount / ro during normal operation. Separate disk? That depends on how much use /tmp and / get and whether they get in each other's way.

As for parts 1 and 2, on my box (Mac OS X) the /var/tmp is not cleaned out daily but /tmp is, so they have different policies and therefore should not be symlinked together. I'm not sure that cleaning /var/tmp daily wouldn't break anything and would want to investigate that before becoming more vociferous - it's only 172k at the moment.

share|improve this answer
add comment

One item I would consider - in reference to your last question - is to make /tmp noexec,nosuid - that is, no executables will be able to run from /tmp, and no suid binaries will be able to switch userid. However, this might affect some programs, so test it before you rely on it completely - I think ssh was even one of these, but I forget.

This is a security measure that will improve your security in regards to /tmp.

Another thing: a lot of users will try to use /tmp as permanent temporary storage: any enforced cleanup of /tmp has to be done along with education of the users: remind them that /tmp is temporary and anything placed there can disappear at any time.

share|improve this answer
add comment

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

Have you considered what happens when /tmp fills up in this situation? It's not the sort of thing you do twice. I've done it once (on Solaris /tmp will eat up all available RAM and swap), and it brought the server to it's knees.

share|improve this answer
add comment

Your Answer

 
discard

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.