Tmpfs

Okay, hear me out: tmpfs actually has some weird and surprising behavior sometimes and it's worth knowing how it actually works and what happens when it doesn't work or isn't used in the places you expect.

For those not in the know, tmpfs is used when you want to mount a directory to memory. It's an entire filesystem, but directly in memory. This has the added effect that, when you reboot your Linux machine, it's cleared out. You'll very, very often find that your /tmp directory is a tmpfs filesystem. While lesser-known, it's the same story with /dev/shm.

One would assume that a tmpfs filesystem would have the same amount of storage space as you have RAM, but that's not quite correct.

By default, all tmpfs filesystems will have half of your available RAM set as their maximum size. If you need to manually set the size, however, you can use the size mount option. eg.

For an fstab entry, it would look like this:

A single tmpfs filesystem can have a maximum size of +. This means you can have a tmpfs system larger than your maximum RAM, but doing this will absolutely cause you massive problems if it ever fills up.

In short: anything you put in /tmp will stay there until it's manually deleted or cleaned up by a sysemd-tmpfiles. The contents of /tmp don't get wiped automatically on reboot unless you clear it out manually or set up a systemd-tmpfiles rule to do so on a regular basis.

Not-so-temporary, eh? In hindsight, this should have been obvious for me, but I really only started figuring this out after working with CIS benchmarks and STIGs which tell you to use a "real" directory or volume for /tmp.

To set up systemd-tmpfs to automatically clean out /tmp on boot (the behavior you'd expect) do the following steps:

And you're done! It's easy enough to configure (the man page helps a lot) but it's just not obvious that you should configure it.

The systemd-tmpfiles service is quite flexible. If, for example, you'd like to clean out yesterday's files on a regular basis, you can do something like this:

Now, not only will /tmp be completely cleared out on boot, but it'll also stay clean by managing itself.

Good question! How regularly is "regularly", anyway? Well, since systemd-tmpfiles is part of systemd it's safe to assume it has a service or timer of some kind. A quick systemctl status systemd-tmpfiles<tab><tab> confirms this:

And it looks like there is, indeed, a timer. Presumably specifically one for running the --clean operation.

We can look at the /usr/lib/systemd/system/systemd-tmpfiles-clean.timer referenced here to see what that looks like:

This tells us that it will do a first run 15 minutes after a system boot. From that point, it runs once a day.

So, any of your tmpfiles.d files that tell systemd-tmpfiles to clean out old files will run after 15 minutes, and then from there every day. The exact time depends on when (the time of day) the system was booted.

Harkening back to the note on computers for a minute, here, I'll remind you that all data (eg. files) are just a long string of bytes. For permanent storage, those bytes are stored on mediums like disks. In order to use those bytes you first need to load them into memory. To work on a file, for instance, that file (or at least part of it) needs to be loaded into RAM.

Well, when your filesystem is entirely in RAM already, it's pretty easy for the computer to load it up. For systems like Plex, it's recommended to have the transcode directory be a ramdisk (a tmpfs filesystem) for this reason. It's fast. Like, really fast.

Another great reason is why systems have a /tmp directory in the first place: it's nice to have some temporary storage place that everyone can use for various files. Even systemd uses it for some of its stuff. Here's a RHEL system that's been freshly booted up:

Ultimately it's up to you to decide when and how they're used and cleaned. Linux provides some reasonable defaults that most users are used to - so, personally, I'd stick with those. To each their own, though!