Have you ever received an HTTP 418 status code while browsing? If so, it may be because you were trying to put a square peg in a round hole, or vice versa.
Indeed, RFC 2324 Lays out the specification, and Oopsies! It turns out that an April Fools joke was canonized, albeit with some utility. Turns out, even if someone's not trying to pull your leg, by telling you "I'm a Teapot", it's likely you're gently being encouraged to look for a resource other than the way in which you're asking.
For example, you ask for a coffeemaker and receive the error, HTTP 418 (I'm a Teapot). It's certainly nicer that a 404 and yet indicates that there is content where the page you've just asked for exists.
This is in some ways a concern that many have dug their heels in over, clinging as intransigent as ever when it comes to #tmpfs discussions beginning twelve years ago on the #Debian Dev list.
Often, in practice, cron is used to clean out unneeded clutter in /tmp or /var/tmp, as well as other methods. An issue I have is with the systemd defaults including /var/tmp in tmpfs on some implementations because temporary files here are intended to be persistent across reboots.
By default, systemd cleans out files in /var/tmp by default after 30 days, and this can be problematic, while the default is 10 days for /tmp. /var/run and /var/lock are also Incorporated - But I digress.
After well over a decade, about half of the major Linux distros have migrated to tmpfs: Arch, Fedora, and some versions of SuSE number among the most familiar. Others have not: Redhat, SLES, and other "Enterprise" focused distros, along with Debian, ... Until just recently, when much to my surprise during routine updates I noticed the switch to tmpfs has now occurred.
w00t š¤š¤ š¤
With respect to Slackware, does it use the traditional disk based method or the RAM based tmpfs? The answer to that of course, is "Yes, of course, it absolutely does!"
"Which one did you say?" I actually didn't, lolz. As is usually the case with Slackware (and Arch and Gentoo), it's really however you want it!
In Slackware, the implementation is much more elegant however. You simply mount /tmp on a ramdisk (again, leave /var/tmp alone - these files are intended to be persistent across reboots, and for possibly much, much longer than a mere 30 days).
Okay so back to Debian. If you're one of those fraidy cats that doesn't believe, or rather, isn't competent or confident enough to run Enterprise production machines on rolling distros, I've got good news for you! You won't be needing to concern yourself with this until Debian 13 is officially released or you're forced to upgrade to it in the next few years. Lucky you!
For the rest of us however, already running #Trixie, it has indeed arrived. Welcome! Here's the problems...
You may, depending on what daemons you run in production, want to tweak your defaults. i.e., 10 days may be less than appropriate for your company's needs. Remember, #cron is your friend. It's also why Slackware's approach was referred to as elegant, because you have to take into account what it is you want or need before you implement it.
For example, since you already know that you don't want temp files to survive reboots in /tmp, there's really nothing faster than disk space residing in RAM anyway.
On the other hand, Poettering doesn't make up the rules for the developers of this world or sysadmins. If you're not careful you can wind up right back on a spinning disk platter again, since the default for #systemd is to allocate 50ā° of your RAM for tmpfs, if you don't have ample memory, you go to SWAP.
Oh, the irony :p
When you're in an HA environment where your UNIX boxes have uptimes exceeding 800+ days, and the only reason to reboot is to install a new kernel, Poettering's 30 day default storage for tempfiles in /var/tmp, or for that matter, a default for files in /var/lock or /var/run, ... is absolutely absurd - this is why we have cron and shell scripts (and Perl/Python).
tl;dr: This is why I started of with that amusing simile about HTTP 418, because if you just trust systemd to hold your hand, you just may find that one of your mission critical Enterprise services informs you that it's been told it's a #Teapot š«
That's not a good thing when 5, 500, or 50,000 people expect their shit to just work without ever having to know your name as the person who makes that happen for them.
Disk based storage is the safe bet; that's why #Redhat still does it that way. But it's certainly not the most performant, and requires the steady fingers of a competent systems administrator for the care and feeding of the tmp file systems - otherwise, like so many n00bs have discovered (in the days when hard drives didn't exceed a Gigabyte in capacity), you may wake up one day to find that you've hammered your filesystem, everything is running, but nothing is doing anything it's supposed to be doing - now, rm and du have become your best friends until the moment you discover that rotating your log files and keeping /tmp clean is actually part of your job...
Even as a casual workstation user on your personal laptop. It's your job.
For those interested, here's an example of the systemd defaults for tmps should you wisely consider the beneficial consequences of responsible planning for managing the size of your growing tempfile directories, from the Arch Wiki:
/etc/tmpfiles.d/tmp.conf
# see tmpfiles.d(5)
# always enable /tmp directory cleaning
D! /tmp 1777 root root 0
# remove files in /var/tmp older than 10 days
D /var/tmp 1777 root root 10d
# namespace mountpoints (PrivateTmp=yes) are excluded from removal
x /tmp/systemd-private-*
x /var/tmp/systemd-private-*
X /tmp/systemd-private-*/tmp
X /var/tmp/systemd-private-*/tmp
Umm... 10 days, /var/tmp? IMNSHO, that's maybe just a tad (way more than a tad) aggressive.
Although I've so far only alluded to it, I actually do recommend that you consider removing /var/tmp from any cleanup schedule too, instead using cron and shell scripts, along with a little proactive monitoring to keep that part of your tempfile systems clean.
And remember: "You may be short, and you may be stout, but unless it's April 1st, don't let anyone call you a Teapot." š«
For further reading you can checkout the [LWN article here] (https://lwn.net/Articles/975565/?ref=news.itsfoss.com).
As always, feel free to boost and share this with others (sharing is love), and I'm always interested in hearing your thoughts and suggestions in the comments.
I hope that helps. All the best!
#tallship #FOSS #Linux #Slackware #Arch #Gentoo #SuSE #Fedora
āµ
.
