Linux server out of space

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.

For those who don't have an account on the forums (or don't wish to login):

if your main issue is not to ping but to ssh, you can create/edit your ~/.ssh/config adding lines like these:

Host fakehost1
  Hostname real-hostname

Host fakehost2
  Hostname real-hostname2

Host fakehost3
  Hostname real-hostname3