== Why I hate having _/tmp_ as a tmpfs

There is a [[recent move in Linux
https://fedoraproject.org/wiki/Features/tmp-on-tmpfs]] to turn _/tmp_
into a tmpfs. As a sysadmin, I am afraid that I have a visceral dislike
of this (and always have).

The core problem with a RAM-backed _/tmp_ is that it creates a new easy
way to accidentally DOS your machine. When _/tmp_ is only a disk, it's
pretty clear how much space you have left and filling up _/tmp_ is only
a minor to moderate inconvenience. When _/tmp_ is backed by RAM, filling
up _/tmp_ means driving your machine out of memory (something that Linux
generally has an explosive reaction to). Worse, how much _/tmp_ space
you really have is unpredictable because it depends on how much RAM
you need for other things. In theory this might be predictable, but in
practice RAM demands are subject to abrupt and rapid swings as programs
start and stop and change what they're doing.

(Even without a bad reaction from the Linux kernel to an OOM, an OOM
situation is both worse and more wide-ranging than having _/tmp_ or even
the root filesystem run out of space. Being out of memory affects pretty
much everything on the machine, and that's assuming you don't have [[enough
swap space to cause your machine to melt down ../sysadmin/SwapSizingII]].)

This is bad enough on a single-user machine, where at least you are
only blowing your own foot off when you DOS the machine through an
accidental OOM because you (through old habits) or your program
(through not being revised to [[the latest nominal standards
http://0pointer.de/blog/projects/tmp.html]]) innocently put something
sufficiently large in _/tmp_. On shared multi-user machines, it's pretty
close to intolerable; the damage done is much larger and so is the
chances of it happening, since all you need is one person to have one
accident.

(By the way, this is not theoretical. We have had people put
multi-gigabyte temporary files in _/tmp_, especially on our compute
servers. Sometimes they manage to fill _/tmp_ up, even though it has
many gigabytes of disk space.)

Ultimately, what making _/tmp_ into a tmpfs does *in practice* is
to make the machine more fragile. How much more fragile depends on
what happens on the machine, but it's undeniably more fragile. I
don't like things that make my machines more fragile, so I don't
like this.

By the way I'm aware that other systems (such as Solaris) did this years
ago. I didn't like this transition on them either, for exactly this
reason. I consider it a really good thing that only staff can log on to
our Solaris machines, because a RAM-backed _/tmp_ makes them too fragile
for me to be happy with general access to Solaris.

(See also [[SysAdmin1138
http://sysadmin1138.net/mt/blog/2012/03/moving-tmp-to-a-tmpfs.shtml]].)

=== Sidebar: the right way to do this transition

It's really simple: make a new _/tmpfs_ mount point
that is, well a tmpfs. [[The latest new standards
http://0pointer.de/blog/projects/tmp.html]] make it clear that any
number of programs need revising anyways to put their data in the right
place; while you are revising those programs, you can perfectly well
make them use _/tmpfs_ when appropriate. And the result does not blow
people's feet off when they continue following decades of user behavior
and program defaults. If you want and it makes you feel better, you can
then make _/tmp_ into a symlink to _/var/tmp_.

(As usual, this is certain Linux people [[not solving the real problem
../tech/SocialProblemsMatter]].)