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:
- All files are transitory, and are not guaranteed to survive a reboot.
- 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.
Its original use was to provide a hint to the OS that the executable should be cached in memory so it would load faster. This use has mostly been deprecated as OSes are pretty smart about this sort of thing now. In fact, I think now some OSes use it as a hint that the executable shouldn’t be cached.
The most common use today is to create a directory in which anyone can create a file, but only the owner of a file in that directory can delete it. Traditionally, if you have a directory that anyone can write to, anyone can also delete a file from it. setting the sticky bit on a directory makes it so only the owner of a file can delete the file from a world-writeable directory.
The classic use of this is the /tmp directory:
$ ls -ld /tmp
drwxrwxrwt 29 root root 5120 May 20 09:15 /tmp/
The t in the mode there is the sticky bit. If that wasn’t set, it would be pretty easy for a regular user to cause havoc by deleting everything from /tmp. Since lots of daemons put sockets in /tmp, it would essentially be a local DOS.
Best Answer
Sounds like a recipe for disaster.
You can use anything other than / - but you might want to wrap in single quotes (') to avoid execution of special characters.
eg. $*`\|
Using special characters in file names is very much a Windows-ism - mostly taken from GUI machine administration versus command line (which doesn't lend itself to continuously having to escape file names).
The safest approach is just to stick to a-zA-Z0-9_.