16 ms·

Debian's /tmpest in a teapot

204 points by jwilk 2y ago

quesne 2y ago
In addition to this upgrade, debian has removed the 'last' command and related data files.
candiddevmike 2y ago
/var/tmp, IMO, shouldn't exist--the idea of temporary files that should persist beyond a reboot is tech debt, those files should exist under a proper /var/{cache,lib} directory. Podman uses this directory and it drives me nuts. The XDG base directory spec (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-...) was supposed to solve all of this...
- deleted 2y ago
  [deleted]
- zbowling 2y ago
  Nah. XDG base directory was supposed to solve a ton of things 18 years ago, except none of them are hard-hitting user problems most folks really care about most of the time unless you are really anal about hidden folders in your home directory polluting things up (most people aren't), so it fails with partial support from apathy from some package devs on Linux to implement it. Honestly, we should probably abandon the hope that we will ever get full universal adoption. It stinks even worse with the half-adoption state we are in now, with some apps writing to those directories and other apps not. If it wasn't for arch Linux folks trying to drive apps to adopt it more, I don't think it would be. Hell, default Debian/Ubuntu still doesn't set XDG_* directory ENVs by default (some flavors do), and some apps ignore the prescribed "if not set, use this default" nonsense in the spec and do what they have always done because it doesn't break compatibility for users. Part of the spec stinks, too, like the spit between cache/config/data config where the spec has no written rules specified on when anything is expected to be cleaned up and when or what can or should be backed up by the user. Let's move to containerizing most apps, putting everything in little jails so we don't have to deal with where they want to write to. They can have their own consistent and expected behaviors on their own island. Snapcraft, flatpack, or any of a bunch of other solutions are already available to solve this problem. Don't have to worry about what some app left behind or wrote to your system when it's all contained.
  - 38 2y ago
    [flagged]
    - zbowling 2y ago
      Guess you have never used https://snapcraft.io/ https://snapcraft.io/, https://flatpak.org/ https://flatpak.org/, or https://appimage.org/ https://appimage.org/ because all of these do exactly that. Snap apps are straight linux containers and the others root like chroot jails I believe still. Or even go take a look at Nix/NixOS and how they pull it off in another way. They have hermetic isolation down to a science. Or heck, just look at what Android does, running each app under its own uid/gid, sandboxing 3rd party code, and keeping each app from reading and writing outside their little jails. Can't pollute a user directory or even write to /tmp if your user can't even enumerate it. Hell, even built a whole sandboxing capability-based security model inside of Fuchsia at Google, which I worked on for 5+ years. I've been building OSs for 20+ years, between Fuchsia and Android at Google and mobile/embedded products at Texas Instruments, so I hope I know what I'm talking about.
      - fragmede 2y ago
        Or Qubes, which goes further and features per-app VMs. Snaps was foisted on the community which was then unwelcoming of it, but per-app isolation isn't the worst idea.
      - Brian_K_White 2y ago
        Android is a thoroughly managed appliance, not a general purpose OS. Snaps should not exist. Flatpak and appimage should exist, but should not be used except in extreme cases. You can have bad judgement for 20+ years easily.
        zbowling 2y ago
        Nah. Your objections are rooted in the very limited definition of what an OS is and what a user application model is that fits it. There is no reason why each process/app can't be sandboxed. In fact, it should be for security (we did it in fuchsia). It's actually the way things work with apps from the app store on MacOS in a lot of ways where you can't escape your jail except through what is explicitly entitled. General purpose just means that it's generally useful for a wide range of applications. Android is that. Hell, you can find Android running small appliance server infrastructure and powering IoT devices. Even in 2024, iOS/iPadOS is general purpose at this point, and they have VERY different application models from legacy app models you find on Windows and Linux. You wouldn't not call NixOS a general-purpose OS, and it's like flatpak for literally every process down to things like bash, grep, and vim. Snaps are fine. Aversion is only from how it was introduced to people in Ubuntu, but conceptionally, is great. cgroups wrapping user processes to box them is not only good for security but also for stability and solving dependency versioning issues. It's brilliant. It's similar to what we did in Fuchsia at Google (we took it to another level because we had no legacy to deal with). And sure, maybe I have bad judgment on some things. I contributed a ton to GNOME in the early 2000s both code and ideas that were horrible in hindsight, but I'm not still stuck in an outmoded mental model for thinking about my user environment.
- NekkoDroid 2y ago
  /tmp/ is the ram-backed version for small files, while /var/tmp/ is the disk-backed version for large files and I also think both should be clean at bootup. In my personally opinion the reaping period is way too long, especially for /tmp/ as only few people really have an actual uptime that long but it does make somewhat sense for /var/tmp/ as it currently is "persistent".
  - deleted 2y ago
    [deleted]
  - hda111 2y ago
    Depends on the distro. In Debian /tmp is backed by the disk.
    - bayindirh 2y ago
      > In Debian /tmp is backed by the disk. In Debian /tmp was backed by the disk. Trixie will come with RAM based /tmp. Update is pushed.
    - jkaplowitz 2y ago
      The article we’re discussing is exactly about Debian changing that for the next release. (The only thing that will be changing in this respect is the default, and possibly the configuration at the moment of upgrade to the next release. Debian has long allowed users to configure both RAM-backed and disk-backed /tmp, and both will remain possible.)
  - Terr_ 2y ago
    > I also think both should be clean at bootup. I'm OK with a RAM-backed /tmp getting cleaned every boot simply because that's part of the technical tradeoff, however "on boot" is a bad trigger because its behavior is unreliable and can easily backfire and harm a user. A classic example would be if the power is interrupted and the computer restarts. Unless the user is present and savvy enough to block it somehow, all of their short-term "throwaway" project/data just got deleted before they actually finished with it. In other words, the difference to users between "I won't need this after tomorrow" versus "I won't need this by next boot" can be very important.
- throw0101c 2y ago
  > is tech debt Or it's useful system behaviour. To-MAY-to, to-MAH-to. > […] should exist under a proper /var/{cache,lib} directory. Are these directories available to regular users like the tmp dirs are?
  - Smar 2y ago
    /home/.cache/ is for regular users.
    - thayne 2y ago
      System users often don't have a real home directory, but need somewhere to write files too.
      - karmarepellent 2y ago
        If feel like this is the moment where these discussions about old filesystem layouts start to go in circles. Yes, system users tend to not have a home directory. But you are fully able to create one for a new system user if this is what you want to do. You are also able to create all kinds of temporary directories and read-only filesystems for a process (e.g. using systemd) if this is what you want do to. Yes there is a lot of fragmentation and no real standard, which is a little disappointing, but you sure have options to work with. And these options do not have to involve any legacy-ish filesystem components like /var/tmp that nobody knows the purpose of.
        thayne 2y ago
        > filesystem components like /var/tmp that nobody knows the purpose of The purpose of /var/tmp is temporary files that should survive a reboot. A potential example where that would make since is a partial download file. It is only needed temporarily but if a reboot happens while the download is in progress, you probably don't want to have to start over. Also if /tmp is or might be a tmpfs, it is probably desirable to use /var/tmp for larger temporary files that don't fit in RAM.
    - 2y ago
- pjmlp 2y ago
  As someone that knows Linux since Slackware 2.0 in 1995, the adaption of XDG has been quite flexible across the Linux/BSD landscape.
- belorn 2y ago
  They could merge /var/tmp and /var/cache, with the intention to discourage future use of /var/tmp. With users, programs and admins already using /var/tmp as a persistent cache, a name change seems like the best solution.
- tremon 2y ago
  Actually, no. The XDG specifications are intended for desktop environments, the focus is on end users throughout the specs. System services and their locations are out of scope. The standard for filesystem layout was the Filesystem Hierarchy Standard [0], which predates the XDG by about a decade. Although Debian-before-multiarch was the distribution that most closely adhered to the FHS, it was not a Debian-only document. That being said, all my systems have /var/tmp as just a symlink to /tmp, regardless of what the FHS may have to say about it -- and it's cleaned weekly, not just on reboot. [0] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.htm... is the current home, apparently
shadowgovt 2y ago
While I generally appreciate Debian's careful approach (it is my go-to distro if I want things to be predictable with minimal upgrade frequency), it always blows my mind to watch open-source communities bury topics like this in committee for twelve years while commercial OS's just tend to go "It's better for the end user. Here's some money. Make it work. If it breaks some key software, make it work."
- codetrotter 2y ago
  In fairness it did say: > Red Hat Enterprise Linux (RHEL) and its clones, as well as SUSE Linux Enterprise Server (SLES) and openSUSE Leap, still default to /tmp on disk. So at least some commercial OSes, if you will agree that we could refer to the first two of these distros as such, are also staying with old decisions for a long time. And even though RHEL in particular is know for its insane dedication to keeping API compatibility with backports of software, they still are in a position to change things around between major versions. And I believe they do do that quite a bit, which is why they also give so long time before EOLing old versions so that enterprise has plenty of time to adapt to the changes with major version upgrades.
- pantalaimon 2y ago
  But how is it better to have /tmp on tmpfs? Those files are hardly performance critical
  - shadowgovt 2y ago
    Flip the question: most storage these days is some kind of solid-state. Why is it better to commit /tmp to a solid-state device (decreasing its operational life) when those files are, by definition, transient and must not be required for future correct program operation?
    - pantalaimon 2y ago
      Because the alternative is more precious RAM
neilv 2y ago
In addition to `/tmp`, you can put your `~/.cache` on `tmpfs`. Laptops have ridiculously large amounts of RAM nowadays. My Linux laptop setup barely makes a dent in the RAM, even when running 3 different Web browsers and other gluttonous desktop programs. `tmpfs` is a great use for excess RAM, reducing wear on SSD. (I also disable swap.) I've also done things like build an entire large ecosystem of packages in `tmpfs`, when the build server happened to have mirrored 10krpms drives, and I didn't want the tons of intermediate files to eventually be synced to disk. (Even though, with disk, they would also probably hang around in Linux filesystem buffers, not reads hitting disk each time.)
- deleted 2y ago
  [deleted]
- zbowling 2y ago
  This would break a bunch of little things in annoying ways. Like I have shell script tools that store shell scrollback logs in .cache, and I want that past reboot.
  - neilv 2y ago
    FWIW, I've been doing it for many years, and not noticed any problems. If something is supposed to persist past reboot, I wouldn't put it in `.cache`. Though I don't know offhand what the official documented behavior of `.cache` is, and I can't immediately find that documentation (maybe some open desktop cabal thing?).
    - mhitza 2y ago
      XDG_CACHE_HOME same text across bott resources https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... or https://wiki.archlinux.org/title/XDG_Base_Directory https://wiki.archlinux.org/title/XDG_Base_Directory > $XDG_CACHE_HOME defines the base directory relative to which user-specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.
iforgotpassword 2y ago
I prefer /tmp on disk. Nvme disks are fast enough, wear is not an issue nowadays. I occasionally extract large files there. So either the tmpfs would be too small or the machine would eventually start swapping random things to disk, for which I'd have to grow my swap partition first - it's only 1GB. I mean I could start using /var/tmp or make a directory in $HOME and clean that up occasionally, but that would mean I have to change old habits. ;) so I guess masking tmp.mount it is.
JonChesterfield 2y ago
Tmpfs is great. If you're a compiled language person and the build dir isn't in a tmpfs yet, give it a try. Faster than nvme and less prone to burning out from lots of writes. Defaulting to /tmp in tmpfs means I can remove a line from my post install setup script. That doesn't matter much. But it also means less divergence between my system and the default, so there should be a reliability improvement from other people stumbling over problems with the ramdisk before me. So a win all around, happy to see it.
- tombert 2y ago
  What's especially fun is using tmpfs as root on NixOS. That way your root partition gets cleared out on any reboot, so cleaning up your mess is never really more than a reboot away. I've never thought about mounting a tmpfs folder for compiling stuff, but that's actually a pretty good idea.
  - Aurornis 2y ago
    > I've never thought about mounting a tmpfs folder for compiling stuff, but that's actually a pretty good idea. Using tmpfs (or RAMDISK) for compiling and discovering that it’s not actually faster is a virtually rite of passage for every developer. :) If you do try it, at least benchmark it. You’ll probably discover that you spent more time setting it up and copying files around to volatile storage than you’d ever gain back via minuscule compile time speedups. Compiling is not IO bound and your files are already being cached in RAM by the OS after the first read.
    - tombert 2y ago
      It’s actually not really about speed in my particular case; I mostly just don’t want lots of tiny intermediate files being written and rewritten on my SSD all the time. I would sleep better if I knew that they wouldn’t have any negative effects on the lifetime of my drive. I have a tmpfs folder mounted for my downloads folder for my browser for similar reasons; not for speed but to reduce drive wear and automatic cleanup so that it doesn’t pile up for forever.
    - 2y ago
influx 2y ago
I was really impressed how Boccassi "project managed" this change, gathering feedback, addressing feedback where necessary, and continued to push the ball forward even under lots of objection. Many people would have just given up and the status quo would have remained for another couple years.
- dsr_ 2y ago
  Excepting a General Resolution or a Policy violation, every accredited Debian Developer can do whatever the heck they feel like in their own packages. This can pose problems. Boccasi steamrollered, but relatively politely.
  - KennyBlanken 2y ago
    Beyond "relatively politely." People were more interested in bitching about edge cases where maintainers / projects / authors were doing things they should not have been doing in the first place than they were about addressing those issues, so he addressed them himself. The man literally put up when others would not shut up.
    - guappa 2y ago
      The fact that YOU don't have a particular use case doesn't necessarily mean much. Billions of people don't use linux and this all doesn't matter to them. But perhaps 30% could be in what you call "edge case", since your statistics is entirely based on yourself.
      - blucaz 2y ago
        The fact that YOU have a particular use case doesn't necessarily mean much either. Just customize your configuration accordingly, and move on.
        guappa 2y ago
        But according to you, anyone who isn't "bluca" is an edge case :D
pm2222 2y ago
Oh really I thought my arch should only clear /tmp upon startup. No wonder I lost files in /tmp The upstream defaults for systemd are to mount /tmp as a tmpfs and delete files that have not been read or changed after ten days in /tmp and 30 days for those stored in /var/tmp.
- liveoneggs 2y ago
  gross.
ars 2y ago
It's a lot slower to write a large file to a ram based /tmp and let it swap out, vs writing that file to disk directly. If they want to do this they need to modify tmpfs to do a better job of shifting data to disk when full, instead of letting swap handle it.
- throwaway984393 2y ago
  You can specify the size of the tmpfs and keep it well below the size of RAM, which will greatly reduce the likelihood of a long-lived tmpfs from causing swapping. But more importantly, don't write large files to /tmp/. Back in the day we gave /tmp/ its own partition just so those files didn't fill up the root mount. Write big files there and it would fill up. Plus, big files benefit more from a faster drive, and back in the day we used to put the root mount on a slow disk, and have a fast big data disk which is better for large files. I think an option to prevent tmpfs from getting shifted to swap (or disk) at all would be great.
- MrDrMcCoy 2y ago
  Not true if you enable zswap. The pages stay compressed in a RAM pool, and are only sent to the real swap on disk in their compressed states when that gets full. This significantly reduces I/O overall.
probably_wrong 2y ago
I've had cases where /tmp was full, usually by some runaway program that didn't clean up properly. The first indicator is usually that Bash auto-complete fails, followed by no one being able to SSH into the machine. I suppose mounting /tmp in RAM means this will happen more often (as RAM is usually smaller than hard drive space), but I don't see this becoming a giant issue. Now, auto-cleaning /var/tmp... that's going to cause SO MUCH data loss across people I know. I see a parallel with keeping files in your Desktop: yes, that's not what it's there for and ideally you'd store things properly, but you don't go around deleting people's documents just because you don't like it! Time to start sending warning E-Mails, I guess.
- camel-cdr 2y ago
  I quickly ran a backup just now, but I would've been one of the people slightly effected. I symlink some of the desktop cache files to /var/tmp, but since that never got deleted for me (on Debian and Manjaro) I also started linking things like my browser profile there. I kind of knew that /var/tmp may not be the correct folder for it, but if it works, it works you know. A bit of background on my setup, for why I even want to create such symlinks. My home folder is on an automatically mounted USB stick that I transfer between systems (laptop and desktop). On shutdown, I rsync the home folder to a local backup folder, which gives me a small distributed backup system. Using the same home directory between systems with different distributions and CPU architectures (I'm using the pinebook pro arm laptop) works surprisingly well. But I'd rather not stress the USB stick with a bunch of frequently accessed cache files, hence the symlink. I end up also symlinking the browser profile, because that caused version incompatibilities between systems, and I'm ok with having local browser settings/history on each device.
  - somat 2y ago
    I sort of do the same thing, See, I like my homedir on a nfs share. (my philosophy is build one really good drive, raid, backups etc, then everything can use that, rather than try and put a good drive into everything) However there is stuff I don't really care about but would like to be fast and don't want eating my bandwidth, caches mainly, Now unlike you I tried to stay out of tmp so I made a /var/home/ on a fast local drive that vaguely mirrors /home and symlink the caches into it. That way it makes a good dedicated space for when I do want a fast local filesystem. As an antidote I had a hard time for a few years after I stopped using irix, I wanted(or at least my fingers wanted) the home directories to be under /usr/people
aftbit 2y ago
The discussions about swap in the LWN comments are interesting. I wasn't aware that at the "swap should be 2x RAM" tip was actually a hard requirement at one point (allegedly around Linux 2.4). I also wasn't aware that common recommendation was to run with swap again. I have some systems (usually VMs) where RAM is much bigger than the root disk. For example, 500+ GiB of RAM and only 100 GiB of disk. I have other VMs where the disk is orders of magnitude slower than the RAM (e.g. EBS on AWS EC2). I wonder what I should be doing for swap and vm.swappiness. Usually I just run with either no swap or a tiny 4 GiB swap file on /.
- lionkor 2y ago
  On real machines I run with a super low swappiness of 1-5 or so, which effectively means it will always use RAM, basically until its too late. That way its difficult to accidentally get OOM killed, instead everything just slows way down when swap gets involved when RAM is full.
  - IshKebab 2y ago
    Yeah the trouble is in my experience it slows down to the point that the system is unresponsive and you have to reboot anyway. I don't think Linux has a good answer to RAM management other than "buy lots and lots of RAM" (I already have 32GB and it's nowhere near enough). I wish it worked like Windows - I've never had to reboot due to lack of RAM there, and even when the system is unresponsive ctrl-alt-del is very reliable.
    - dspillett 2y ago
      I've had Windows hang due (apparently) to OOM before now, most recently last week: already low on free memory due to other things, a runaway chrome tab chef through a huge pile of memory overnight. Come morning everything was at a crawl (task manager responded quickly but everything else took an age to register any event like a click or keypress. Bringing up chrome's task manager, sorting by RAM use, and navigating to the top of the list, to find the problem, took several minutes. Switching to that tab hung everything, even task manager. This was running in a VM so I could see from the host that the OS has hung: practically no CPU or IO use, what little there was was likely just "background noise" from hyper-v, also not even the simplest service accepted TCP connections nor would it respond to ping. Left it like that for tens of minutes to see no change, so resorted to a hard stop & start. It happens, albeit quite rarely.
bdjsiqoocwk 2y ago
Very OT, but I don't know where else to turn to because the Reddit community has been of no help. I used i3 and I absolutely love the way it feels. However I would like to configure it in a way that I can press a button and every app turns into dark mode. My main apps (Firefox, vscode) have an option to say "use system theme" i.e. if the os is dark, theme this app dark. Great! The problem is I don't know how to set the system theme. And every time I've asked around, I see people respond with GTK, QT and what not. I don't have those, I have i3. Help?
- Arnavion 2y ago
  What those people told you is correct, and "I don't have those, I have i3" is incorrect. Stop ignoring them.
  - bdjsiqoocwk 2y ago
    I'm not ignoring. I still don't know how do I enable dark mode. If you have the answer, would you kindly help?
    - singron 2y ago
      i3 is just a window manager. It's not a UI toolkit. It doesn't control how apps render UI. GTK and QT are UI toolkits and do control how apps render UI. Your apps will use GTK and QT even if you use i3 to manage the windows. You might be confusing GTK with Gnome and QT with KDE, each of which has its own window manager.
      - smegsicle 2y ago
        so you're saying to get gtk apps to switch to dark mode, you'd find the gtk setting for dark mode? and the same for qt?
        viraptor 2y ago
        Yes, for example check "gsettings set org.gnome.desktop.interface gtk-theme" for the gtk apps.
pantalaimon 2y ago
I don’t like it, I tend to use /tmp for large files or directories that are just that - temporary. Now they will either fill up my RAM or require a large swap partition (which I usually don’t have as it’s otherwise wasted space). I really like making /tmp the default destination for downloads, so either I need the file and move it elsewhere, but usually it’s an archive and I just want a file from it. Saves me from an ever growing Download folder. Those files are most dispensable and should not consume precious RAM. Some file systems are even adding specific tmpdir support where fsync() is turned into a noop. So they have all the advantages of tmpfs without eating into precious RAM/Swap.
- stouset 2y ago
  It's a default. You can change it.
  - pantalaimon 2y ago
    Only on my personal machine. If I’m logged in elsewhere and keep my habit of working on large files in /tmp, I will be in for a bad surprise
    - stouset 2y ago
      So… don’t keep large files you want to control the lifecycle of in directories you don’t own? If you care about it, stop putting it in /tmp. You were always setting yourself up for a bad surprise by doing this, and now you’re surprised?
      - pantalaimon 2y ago
        I might download an ISO or check out a repo I want to build just once. Or copy some (large) files there because I run a script on them and persevere the original in case something goes wrong. I don’t care about those files once I’m done with them - so far they would only be gone with a reboot, which aligns well with my definition of done.
rwmj 2y ago
What's the point of putting /tmp in RAM when a competent disk-backed filesystem will do that with the most heavily used files anyway?
- kasabali 2y ago
  Change for the changes sake, of course.
- pjerem 2y ago
  You gain writing cycles that are not going to wear out your SSD for files that are going to be erased anyway.
- silisili 2y ago
  It's A) much faster, B) causes less wear, and C) automagically cleans itself, so to speak.
  - pantalaimon 2y ago
    What about tmpdir as proposed by bcachefs? [0] That keeps the file in the page cache until it’s evicted, but instead of being written to swap it’s written to the fs. With the swap partition usually being quite small and the fs today being all the storage there is on a personal machine. [0] https://bcachefs.org/Roadmap/#tmpdir_support https://bcachefs.org/Roadmap/#tmpdir_support
    - arp242 2y ago
      Well, as I read that page it doesn't actually exist (yet), so that rather makes it a hypothetical at this point. Might be interesting in the future, but not today.
    - MrDrMcCoy 2y ago
      It's a neat idea, but I doubt it'll take off. Swap with zswap as a backing for tmpfs should be plenty for the time being.
- 2y ago
dur-randir 2y ago
[flagged]
dopylitty 2y ago
I believe I speak for all when I say I keep all my most important files in /tmp and ~/Downloads
- somat 2y ago
  Doing tech support for an office there is always that one guy who keeps his files in the windows trash. No I don't know why either, while not the stupidest thing I have seen, it comes close.
  - john2x 2y ago
    It’s easy to find. It has a unique icon and everything. It even has a dedicated shortcut to move files to it. Why would you not use it?
camel-cdr 2y ago
Is there a easy/non hacky way to configure /tmp to only delete files on regular shutdown? I sometimes have the occasional crash, and have been bitten by doing some temporary work in /tmp before such a crash 2-3 times.
- silisili 2y ago
  You could do this pretty easily I think with systemd, it has a shutdown target that covers reboots and poweroffs. It would of course meaning not having tmp in RAM which is pretty common these days.
hsbauauvhabzb 2y ago
In the article there’s some mention of the implications of ram and swap - this has caught me before - if you wget an iso to /tmp, you may be consuming more ram than expected. And sure, that’ll get swapped out to disk, but that might be unexpected if you’re intending on using ram for virtual machines etc, you may end up OOM because of this behaviour. I did this on Fedora, and it left a bad taste in my mouth.
o11c 2y ago
/tmp on tmpfs is fine. /var/tmp being cleaned on boot is probably fine despite contrary standards in the past. But automatically deleting files - in either of those - while the system is running is going to break all sorts of things. As a random example, `chromium --temp-profile` will have half the profile deleted (since some particular files aren't accessed frequently) while the browser is running. This looks designed to cause system-level UB. Note that locks on directories are pretty rare; locks on a file within the directory are the de facto standard, on the assumption that only cooperating programs will access them.
- lifthrasiir 2y ago
  Indeed. I'm much more worried about partially deleted files in `/tmp` than the fact that files in `/tmp` do eventually get deleted.
- dheera 2y ago
  > But automatically deleting files - in either of those - while the system is running is going to break all sorts of things. Detect the process that created a file and delete it 24 hours after the process ends.
  - jgalt212 2y ago
    Thanks for the homework assignment. The entire value proposition of tmp is there is no homework to do later.
  - leni536 2y ago
    Chrome is multi-process, isn't it?
  - blucaz 2y ago
    Or what about, delete it after 10 days it was last accessed (regardless of whether for read or write)? Hint: that's already how tmpfiles.d works
  - o11c 2y ago
    That will fail badly with multi-process programs, which includes the example of browsers, and many others (databases anyone?).
throw0101c 2y ago
From FHS: > The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp. > Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp. * https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.htm... IRIX docs: > The directories /usr/tmp.O, /var/tmp, and /var/spool/uucppublic are public directories; people often use them to store temporary copies of files they are transferring to and from other systems and sites. Unlike /tmp, they are not cleaned out when the system is rebooted. The site administrator should be even more conscientious about monitoring disk use in these directories. * http://rsusu1.rnd.runnet.ru/sgi/advanced/ch8.html http://rsusu1.rnd.runnet.ru/sgi/advanced/ch8.html From FreeBSD 1.0 (July 1991): /var […] tmp/ temporary files not removed between system reboots vi.recover/ recovery files for the vi(1) editor * https://man.freebsd.org/cgi/man.cgi?query=hier&sektion=7&manpath=FreeBSD+1.0-RELEASE https://man.freebsd.org/cgi/man.cgi?query=hier&sektion=7&man... This is also true for Solaris, which I used to admin many moons ago. So I'm not sure where the idea that /var/tmp gets cleaned on reboot came from since I have always understood it to be fairly static.
- SoftTalker 2y ago
  Every unix does its own thing, you just have to know your system. In OpenBSD, /var/tmp -> ../tmp and /tmp is cleaned periodically and not preserved across reboots, but there are some specific exceptions and you have to dig into /etc/daily and /etc/rc scripts to know what they are.
pledess 2y ago
The essence of the problem is that there's no standard pathname for a personal directory that's guaranteed to be on local disk, even if $HOME isn't. Consequently, people have relied on /var/tmp/$USER for this. There are realistically affected users who can't change the new defaults. Cleaning up /var/tmp on a timer is relevant to this academic environment (desktop-based research computing): 1. Each Debian machine is used by only one graduate student, but students do not have root access. 2. Today, /var/tmp is the only persistent local directory where the student has write access ($HOME is on a network filesystem backed up by the university). 3. Within the student population, there is strong institutional memory that /var/tmp isn't backed up by the university and isn't extremely robust (e.g., RAID), but also that nothing there is automatically deleted. 4. Students use /var/tmp for hundreds of Gb of data from simulations that take days or weeks. $HOME is too small and too slow for this. 5. In practice, less than 1% of students lose data through disk failure, accidents, etc. 6. A much larger fraction of students will lose data when sysadmins, who didn't get the memo about the /var/tmp change and thus haven't addressed the ingrained institutional memory, deploy new Debian machines. 7. Some of the students who lose data won't graduate on time.
- kbenson 2y ago
  > The essence of the problem is that there's no standard pathname for a personal directory that's guaranteed to be on local disk, even if $HOME isn't. Consequently, people have relied on /var/tmp/$USER for this. There are realistically affected users who can't change the new defaults. How is that not a site specific problem they introduced? There's no standard pathname because there are valid reasons why you want to have nothing on the local system, such as when it doesn't have a local disk. If you (read as "the admins") have configured the system where there's very few acceptable locations to store local data, and that's a specific need, then it's up to the admins to provide a solution to the problem, not the Debian distro, which is flexible enough to handle this fine. It's not that hard to create your own location for data if you need to, and symlink to it from other locations if required. Need a /tmp/$USER to be a local disk location and /tmp is a ramdisk? Create a script that sets up the correct local location and created a symlink to it in /tmp and make sure it's run on boot and maybe once daily. Both cron and systemd solutions could work for this. Worried that user tmp files will be cleaned out when they shouldn't be? Put in the correct exceptions for tmpwatch or whatever debian uses, or disable that service. Not only is this not rocket science, it's literally the job of the admins that design the OS deployment so that it works for the intended use cases.
throwaway984393 2y ago
I find that, unless there's an extremely necessary reason, it's almost always bad to break backwards compatibility. If there's any concept whatsoever of continuity between major releases, backwards compatibility should be the default, with changes being options. Naturally this leads to more difficulty in testing and maintenance over time. But that extra work pays for the benefit of having a very long lived product and compatibility with past integrations. At the end of the day you have to decide if you're building a product to be easier for the users, or the maintainers. Personally I'm on the side of the users.
dekhn 2y ago
I really dislike people using the "I have an inflexible scientific code that needs /var/tmp to be disk and persisted forever" argument to keep things the way they are. Debian's user base is far larger than a few inflexible codes, and it's straightforward to change the default.
- wang_li 2y ago
  Code and scripts should be well behaved and clean up after themselves. There’s zero reason to periodically go in there and wipe stuff out. Especially when some file systems don’t have a creation time attribute in the on disk inode and some archiving tools preserve the mtime when unpacking. A newly placed file can already be five years old. Also the tone of some of the included quotes is so offputting. Their statements and arguments for this change don’t even acknowledge the fact that there are different views on this. This change comes across as progress for progress’ sake. Makes me want to make a 500TB /var/tmp and never delete anything.
  - Izkata 2y ago
    > There’s zero reason to periodically go in there and wipe stuff out. I swear I remember back when I first switched to linux (Ubuntu) back in the late 2000s, this was how it worked: Instead of a tmpfs or automated wiping on boot, a system crontab entry that would use "find" to delete files last accessed more than some time ago (a day? a week?). Except for the risk of filling the disk if files are created too quickly, this would seem to be the best of all worlds to me - stuff can't stick around forever unless it's constantly being used. A download you access once would stick around for a day, while a heavy project that's using /tmp/ would stick around for the week or month you're using it, even across reboots, then get deleted later.
- alextingle 2y ago
  > it's straightforward to change the default. Care to share? Looking at https://systemd.io/TEMPORARY_DIRECTORIES/ https://systemd.io/TEMPORARY_DIRECTORIES/ and I don't see any description of how to change the default behaviour dictated by systemd. How do I disable the automatic file reaping? How do I configure the maximum age of temp files? Neither are mentioned. The bulk of the page is just a long list of passive-aggressive suggestions about how users are doing things wrong.
LooseMarmoset 2y ago
I have always assumed that /tmp means "temporary". I mean, it's right there in the name. So, a move to tmpfs means "automatic cleanup" to me, which seems just fine, and worth doing for that. If we're doing because the systemd maintainers say "we have to do it because systemd", though, well... How long till the systemd guys make package dependencies and installation as a service? You know, sponsored by the IBM/Redhat team, and signed by Microsoft? signed, a Devuan devotee
- tristan957 2y ago
  systemd is a project which provides building blocks for an operating system. PID 1 is just one building block. Lennart has said this since at least 2013. How the systemd naysayers haven't understood this in at least 11 years, I'll never understand.
skissane 2y ago
I wish Linux (and other Unix-like systems) had an API to let you create named temporary files which are automatically deleted - by the operating system - when a process exits. If you create an anonymous temporary file, then it will be deleted when the last file descriptor to it is closed-but anonymous temporary files are difficult to use (even given access via /dev/fd aka /proc/self/fd). You can delete it using atexit() but that doesn’t get run if the process terminates abnormally (core dump, kernel panic, kill -9, power outage, etc) Maybe something like a pidtmpfs where the top-level directories are pid numbers, you can create any files or directories you want under them, but it all disappears as soon as the process with that pid exits. Actually, pids are a bad idea due to pid reuse, you want something like a process serial number or a process UUID which doesn’t get reused. Another somewhat more flexible idea would be that you can create arbitrary top-level directories, but they - and all their content - are automatically deleted as soon as the last open fd to them is closed. That way you could have multiple processes sharing a temporary workspace, and the workspace could survive the failure of any one of them, but if they all fail it gets deleted
- pram 2y ago
  PrivateTmp in systemd does this.
  - skissane 2y ago
    Unfortunately it only works for systemd units, as far as I am aware. Consider this use case: I have a test program which executes some unit tests, it creates some temporary files. I want the temporary files it creates to all be removed when it exits, even if it core dumps. But while it runs, I want those files to easily be accessible to subprocesses it spawns. I don't think systemd addresses this, because my unit test runner isn't going to be a systemd unit. So really I was talking about a generic facility an arbitrary program could use, not just something limited to systemd units only.
    - Wowfunhappy 2y ago
      > Consider this use case: I have a test program which executes some unit tests, it creates some temporary files. I want the temporary files it creates to all be removed when it exits, even if it core dumps. But while it runs, I want those files to easily be accessible to subprocesses it spawns. For this precise use case, what if you deleted the last run's temporary files at the start of the test program?
aidenn0 2y ago
> Sam Hartman noted that ssh-agent created its socket under /tmp, but it would be better if it respected the $XDG_RUNTIME_DIR setting and created its socket under /run/user. Boccassi agreed and said that he had filed a bug for ssh-agent. Richard Lewis pointed out that tmux stores its sockets in /tmp/tmux-$UID, and deleting those files might mean users could not reattach to a tmux session that had been idle a long time. Boccassi suggested that using flock() would be the right solution to stop the deletion, and said he had filed a bug on that as well. Ah, yet another group of Linux users looking to get ssh to adopt the XDG specification. Moving ~/.ssh to ~/.config/ssh has been repeatedly requeseted. XDG_RUNTIME_DIR is going to be even harder because it can be nonexistent on BSDs.
m463 2y ago
I'm annoyed that it is getting harder and harder to find what physical filesystems are on a system. My goto commands "df -h" and "mount" are cluttered with all kinds of ephemeral filesystems, with no easy way to filter (say, a one-character flag). lsblk is close but .. lvm and snaps.
- ssl-3 2y ago
  On my main-driver desktop box that I hamfistedly switched over to Void Linux (on a ZFS root, even) a couple of months ago: The output of df -h looks pretty sane and understandable. I see some entries for /dev and /run and /, some stuff for EFI, a bunch of mounted ZFS datasets, and it's all very readable with no line noise in any column. --- Now, that said: I have some docker containers. My own previous goto command of mount reports a complete clusterfuck, and all of the clusterfucked lines are due to docker doing docker stuff. I don't know how things like 4UYSHHPFBZQNFZ9Z698JDLUZWJ, LK33RZTN5ZNFGPJNDUHM0HTSD1, 2G0A4YYUVCMP9HZSM5UXOJW0BX, ZH29C5YNZHJ22QMY63EWV5RF3P, and 32XOCXBUY41QQJTPPA8HE6EVZ6 add any coherency or clarity[1], but I assume that since the computer quite easily knows what this shit means then it needn't be bothered with dumbing it down so that a human can parse it in any sort of memorable or repeatable or communicable fashion. (Which is, of course, bad behavior on the part of the computer. A UUID is also awful, but at least it has some punctuation so that it can have some cadence if it must be dealt with as-is. It's like we learned nothing from DNS[2], or as if translation layers can't exist even within a filesystem[3].) 1: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2016788/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2016788/ 2: https://datatracker.ietf.org/doc/html/rfc1035 https://datatracker.ietf.org/doc/html/rfc1035 3: https://linux.die.net/man/1/ln https://linux.die.net/man/1/ln
juliangmp 2y ago
>The knobs to control how /tmp is mounted, and the handling of temporary files, are part of systemd. Huh? Someone explain this to me, wasn't fstab the mechanism to define things like this? Why does my init/service manager need to mess with it???
- zbentley 2y ago
  Systemd has managed mount points on systems where it runs for a long time. It provides mount units an alternative to fstab mount directives, which offers some advantages (including parallelism of at-boot mounting, granular mount dependencies for services, automatic runtime mounting and unmounting) and disadvantages (harder to view at a glance than fstab, more complex). What’s more, on systemd systems, fstab is dynamically converted into native systemd mount units at boot, so in many cases fstab is purely a facade/compatibility shim over systemd doing all the mounting anyway. While not terribly prescriptive, “man systemd.mount” recommends /etc/fstab be used to manage “mounts for humans” due to its simplicity and accessibility. So it doesn’t seem like fstab is considered legacy or deprecated by systemd; rather, this seems like more of a porcelain/plumbing distinction.
M95D 2y ago
Programmers and sysadmins should keep track of their garbage, not break all of our systems just so they can get lazy.
- bayindirh 2y ago
  A competent sysadmin not only tracks their garbage, but others' garbage as well. On the other hand, a sysadmin strives to be lazy, not by postponing problems, but solving them the appropriate way, and preventing it from happening again.
  - M95D 2y ago
    > but others' garbage as well. No! That's what quotas are for. Everyone should keep track of it's own garbage.
    - bayindirh 2y ago
      Who says I don’t use quotas? I just routinely check how everyone is doing, and what my server is doing. That’s all.
bionade24 2y ago
Hopefully Ubuntu will align with this decision, so that MATLAB is finally forced to fix their shitty software. (I am aware that you can set the TMPDIR as an env var)
ericbarrett 2y ago
When I started in tech I worked for a storage vendor’s tech support. One of my first big cases was troubleshooting why a customer’s files older than a week were disappearing. Given the topic, I’m sure you can guess—they had it mounted under /tmp and the cleanup script was doing its thing. Hopefully the new Debian version of this script is a bit smarter!
jimbobthrowawy 2y ago
I only learned that disk backed /tmp/ wasn't the default a couple of months ago after mainly using ubuntu for years and wondering why I was quickly running out of ram on a fedora machine.

204 points by jwilk 2y ago

In addition to this upgrade, debian has removed the 'last' command and related data files.

/var/tmp, IMO, shouldn't exist--the idea of temporary files that should persist beyond a reboot is tech debt, those files should exist under a proper /var/{cache,lib} directory. Podman uses this directory and it drives me nuts. The XDG base directory spec (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-...) was supposed to solve all of this...

deleted 2y ago
[deleted]
zbowling 2y ago
Nah. XDG base directory was supposed to solve a ton of things 18 years ago, except none of them are hard-hitting user problems most folks really care about most of the time unless you are really anal about hidden folders in your home directory polluting things up (most people aren't), so it fails with partial support from apathy from some package devs on Linux to implement it. Honestly, we should probably abandon the hope that we will ever get full universal adoption. It stinks even worse with the half-adoption state we are in now, with some apps writing to those directories and other apps not. If it wasn't for arch Linux folks trying to drive apps to adopt it more, I don't think it would be. Hell, default Debian/Ubuntu still doesn't set XDG_* directory ENVs by default (some flavors do), and some apps ignore the prescribed "if not set, use this default" nonsense in the spec and do what they have always done because it doesn't break compatibility for users. Part of the spec stinks, too, like the spit between cache/config/data config where the spec has no written rules specified on when anything is expected to be cleaned up and when or what can or should be backed up by the user. Let's move to containerizing most apps, putting everything in little jails so we don't have to deal with where they want to write to. They can have their own consistent and expected behaviors on their own island. Snapcraft, flatpack, or any of a bunch of other solutions are already available to solve this problem. Don't have to worry about what some app left behind or wrote to your system when it's all contained.
- 38 2y ago
  [flagged]
  - zbowling 2y ago
    Guess you have never used https://snapcraft.io/ https://snapcraft.io/, https://flatpak.org/ https://flatpak.org/, or https://appimage.org/ https://appimage.org/ because all of these do exactly that. Snap apps are straight linux containers and the others root like chroot jails I believe still. Or even go take a look at Nix/NixOS and how they pull it off in another way. They have hermetic isolation down to a science. Or heck, just look at what Android does, running each app under its own uid/gid, sandboxing 3rd party code, and keeping each app from reading and writing outside their little jails. Can't pollute a user directory or even write to /tmp if your user can't even enumerate it. Hell, even built a whole sandboxing capability-based security model inside of Fuchsia at Google, which I worked on for 5+ years. I've been building OSs for 20+ years, between Fuchsia and Android at Google and mobile/embedded products at Texas Instruments, so I hope I know what I'm talking about.
    - fragmede 2y ago
      Or Qubes, which goes further and features per-app VMs. Snaps was foisted on the community which was then unwelcoming of it, but per-app isolation isn't the worst idea.
    - Brian_K_White 2y ago
      Android is a thoroughly managed appliance, not a general purpose OS. Snaps should not exist. Flatpak and appimage should exist, but should not be used except in extreme cases. You can have bad judgement for 20+ years easily.
      - zbowling 2y ago
        Nah. Your objections are rooted in the very limited definition of what an OS is and what a user application model is that fits it. There is no reason why each process/app can't be sandboxed. In fact, it should be for security (we did it in fuchsia). It's actually the way things work with apps from the app store on MacOS in a lot of ways where you can't escape your jail except through what is explicitly entitled. General purpose just means that it's generally useful for a wide range of applications. Android is that. Hell, you can find Android running small appliance server infrastructure and powering IoT devices. Even in 2024, iOS/iPadOS is general purpose at this point, and they have VERY different application models from legacy app models you find on Windows and Linux. You wouldn't not call NixOS a general-purpose OS, and it's like flatpak for literally every process down to things like bash, grep, and vim. Snaps are fine. Aversion is only from how it was introduced to people in Ubuntu, but conceptionally, is great. cgroups wrapping user processes to box them is not only good for security but also for stability and solving dependency versioning issues. It's brilliant. It's similar to what we did in Fuchsia at Google (we took it to another level because we had no legacy to deal with). And sure, maybe I have bad judgment on some things. I contributed a ton to GNOME in the early 2000s both code and ideas that were horrible in hindsight, but I'm not still stuck in an outmoded mental model for thinking about my user environment.
NekkoDroid 2y ago
/tmp/ is the ram-backed version for small files, while /var/tmp/ is the disk-backed version for large files and I also think both should be clean at bootup. In my personally opinion the reaping period is way too long, especially for /tmp/ as only few people really have an actual uptime that long but it does make somewhat sense for /var/tmp/ as it currently is "persistent".
- deleted 2y ago
  [deleted]
- hda111 2y ago
  Depends on the distro. In Debian /tmp is backed by the disk.
  - bayindirh 2y ago
    > In Debian /tmp is backed by the disk. In Debian /tmp was backed by the disk. Trixie will come with RAM based /tmp. Update is pushed.
  - jkaplowitz 2y ago
    The article we’re discussing is exactly about Debian changing that for the next release. (The only thing that will be changing in this respect is the default, and possibly the configuration at the moment of upgrade to the next release. Debian has long allowed users to configure both RAM-backed and disk-backed /tmp, and both will remain possible.)
- Terr_ 2y ago
  > I also think both should be clean at bootup. I'm OK with a RAM-backed /tmp getting cleaned every boot simply because that's part of the technical tradeoff, however "on boot" is a bad trigger because its behavior is unreliable and can easily backfire and harm a user. A classic example would be if the power is interrupted and the computer restarts. Unless the user is present and savvy enough to block it somehow, all of their short-term "throwaway" project/data just got deleted before they actually finished with it. In other words, the difference to users between "I won't need this after tomorrow" versus "I won't need this by next boot" can be very important.
throw0101c 2y ago
> is tech debt Or it's useful system behaviour. To-MAY-to, to-MAH-to. > […] should exist under a proper /var/{cache,lib} directory. Are these directories available to regular users like the tmp dirs are?
- Smar 2y ago
  /home/.cache/ is for regular users.
  - thayne 2y ago
    System users often don't have a real home directory, but need somewhere to write files too.
    - karmarepellent 2y ago
      If feel like this is the moment where these discussions about old filesystem layouts start to go in circles. Yes, system users tend to not have a home directory. But you are fully able to create one for a new system user if this is what you want to do. You are also able to create all kinds of temporary directories and read-only filesystems for a process (e.g. using systemd) if this is what you want do to. Yes there is a lot of fragmentation and no real standard, which is a little disappointing, but you sure have options to work with. And these options do not have to involve any legacy-ish filesystem components like /var/tmp that nobody knows the purpose of.
      - thayne 2y ago
        > filesystem components like /var/tmp that nobody knows the purpose of The purpose of /var/tmp is temporary files that should survive a reboot. A potential example where that would make since is a partial download file. It is only needed temporarily but if a reboot happens while the download is in progress, you probably don't want to have to start over. Also if /tmp is or might be a tmpfs, it is probably desirable to use /var/tmp for larger temporary files that don't fit in RAM.
  - 2y ago
pjmlp 2y ago
As someone that knows Linux since Slackware 2.0 in 1995, the adaption of XDG has been quite flexible across the Linux/BSD landscape.
belorn 2y ago
They could merge /var/tmp and /var/cache, with the intention to discourage future use of /var/tmp. With users, programs and admins already using /var/tmp as a persistent cache, a name change seems like the best solution.
tremon 2y ago
Actually, no. The XDG specifications are intended for desktop environments, the focus is on end users throughout the specs. System services and their locations are out of scope. The standard for filesystem layout was the Filesystem Hierarchy Standard [0], which predates the XDG by about a decade. Although Debian-before-multiarch was the distribution that most closely adhered to the FHS, it was not a Debian-only document. That being said, all my systems have /var/tmp as just a symlink to /tmp, regardless of what the FHS may have to say about it -- and it's cleaned weekly, not just on reboot. [0] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.htm... is the current home, apparently

shadowgovt 2y ago

While I generally appreciate Debian's careful approach (it is my go-to distro if I want things to be predictable with minimal upgrade frequency), it always blows my mind to watch open-source communities bury topics like this in committee for twelve years while commercial OS's just tend to go "It's better for the end user. Here's some money. Make it work. If it breaks some key software, make it work."

codetrotter 2y ago
In fairness it did say: > Red Hat Enterprise Linux (RHEL) and its clones, as well as SUSE Linux Enterprise Server (SLES) and openSUSE Leap, still default to /tmp on disk. So at least some commercial OSes, if you will agree that we could refer to the first two of these distros as such, are also staying with old decisions for a long time. And even though RHEL in particular is know for its insane dedication to keeping API compatibility with backports of software, they still are in a position to change things around between major versions. And I believe they do do that quite a bit, which is why they also give so long time before EOLing old versions so that enterprise has plenty of time to adapt to the changes with major version upgrades.
pantalaimon 2y ago
But how is it better to have /tmp on tmpfs? Those files are hardly performance critical
- shadowgovt 2y ago
  Flip the question: most storage these days is some kind of solid-state. Why is it better to commit /tmp to a solid-state device (decreasing its operational life) when those files are, by definition, transient and must not be required for future correct program operation?
  - pantalaimon 2y ago
    Because the alternative is more precious RAM

neilv 2y ago

In addition to `/tmp`, you can put your `~/.cache` on `tmpfs`. Laptops have ridiculously large amounts of RAM nowadays. My Linux laptop setup barely makes a dent in the RAM, even when running 3 different Web browsers and other gluttonous desktop programs. `tmpfs` is a great use for excess RAM, reducing wear on SSD. (I also disable swap.) I've also done things like build an entire large ecosystem of packages in `tmpfs`, when the build server happened to have mirrored 10krpms drives, and I didn't want the tons of intermediate files to eventually be synced to disk. (Even though, with disk, they would also probably hang around in Linux filesystem buffers, not reads hitting disk each time.)

deleted 2y ago
[deleted]
zbowling 2y ago
This would break a bunch of little things in annoying ways. Like I have shell script tools that store shell scrollback logs in .cache, and I want that past reboot.
- neilv 2y ago
  FWIW, I've been doing it for many years, and not noticed any problems. If something is supposed to persist past reboot, I wouldn't put it in `.cache`. Though I don't know offhand what the official documented behavior of `.cache` is, and I can't immediately find that documentation (maybe some open desktop cabal thing?).
  - mhitza 2y ago
    XDG_CACHE_HOME same text across bott resources https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... or https://wiki.archlinux.org/title/XDG_Base_Directory https://wiki.archlinux.org/title/XDG_Base_Directory > $XDG_CACHE_HOME defines the base directory relative to which user-specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

iforgotpassword 2y ago

I prefer /tmp on disk. Nvme disks are fast enough, wear is not an issue nowadays. I occasionally extract large files there. So either the tmpfs would be too small or the machine would eventually start swapping random things to disk, for which I'd have to grow my swap partition first - it's only 1GB. I mean I could start using /var/tmp or make a directory in $HOME and clean that up occasionally, but that would mean I have to change old habits. ;) so I guess masking tmp.mount it is.

JonChesterfield 2y ago

Tmpfs is great. If you're a compiled language person and the build dir isn't in a tmpfs yet, give it a try. Faster than nvme and less prone to burning out from lots of writes. Defaulting to /tmp in tmpfs means I can remove a line from my post install setup script. That doesn't matter much. But it also means less divergence between my system and the default, so there should be a reliability improvement from other people stumbling over problems with the ramdisk before me. So a win all around, happy to see it.

tombert 2y ago
What's especially fun is using tmpfs as root on NixOS. That way your root partition gets cleared out on any reboot, so cleaning up your mess is never really more than a reboot away. I've never thought about mounting a tmpfs folder for compiling stuff, but that's actually a pretty good idea.
- Aurornis 2y ago
  > I've never thought about mounting a tmpfs folder for compiling stuff, but that's actually a pretty good idea. Using tmpfs (or RAMDISK) for compiling and discovering that it’s not actually faster is a virtually rite of passage for every developer. :) If you do try it, at least benchmark it. You’ll probably discover that you spent more time setting it up and copying files around to volatile storage than you’d ever gain back via minuscule compile time speedups. Compiling is not IO bound and your files are already being cached in RAM by the OS after the first read.
  - tombert 2y ago
    It’s actually not really about speed in my particular case; I mostly just don’t want lots of tiny intermediate files being written and rewritten on my SSD all the time. I would sleep better if I knew that they wouldn’t have any negative effects on the lifetime of my drive. I have a tmpfs folder mounted for my downloads folder for my browser for similar reasons; not for speed but to reduce drive wear and automatic cleanup so that it doesn’t pile up for forever.
  - 2y ago

influx 2y ago

I was really impressed how Boccassi "project managed" this change, gathering feedback, addressing feedback where necessary, and continued to push the ball forward even under lots of objection. Many people would have just given up and the status quo would have remained for another couple years.

dsr_ 2y ago
Excepting a General Resolution or a Policy violation, every accredited Debian Developer can do whatever the heck they feel like in their own packages. This can pose problems. Boccasi steamrollered, but relatively politely.
- KennyBlanken 2y ago
  Beyond "relatively politely." People were more interested in bitching about edge cases where maintainers / projects / authors were doing things they should not have been doing in the first place than they were about addressing those issues, so he addressed them himself. The man literally put up when others would not shut up.
  - guappa 2y ago
    The fact that YOU don't have a particular use case doesn't necessarily mean much. Billions of people don't use linux and this all doesn't matter to them. But perhaps 30% could be in what you call "edge case", since your statistics is entirely based on yourself.
    - blucaz 2y ago
      The fact that YOU have a particular use case doesn't necessarily mean much either. Just customize your configuration accordingly, and move on.
      - guappa 2y ago
        But according to you, anyone who isn't "bluca" is an edge case :D

pm2222 2y ago

Oh really I thought my arch should only clear /tmp upon startup. No wonder I lost files in /tmp The upstream defaults for systemd are to mount /tmp as a tmpfs and delete files that have not been read or changed after ten days in /tmp and 30 days for those stored in /var/tmp.

liveoneggs 2y ago
gross.

ars 2y ago

It's a lot slower to write a large file to a ram based /tmp and let it swap out, vs writing that file to disk directly. If they want to do this they need to modify tmpfs to do a better job of shifting data to disk when full, instead of letting swap handle it.

throwaway984393 2y ago
You can specify the size of the tmpfs and keep it well below the size of RAM, which will greatly reduce the likelihood of a long-lived tmpfs from causing swapping. But more importantly, don't write large files to /tmp/. Back in the day we gave /tmp/ its own partition just so those files didn't fill up the root mount. Write big files there and it would fill up. Plus, big files benefit more from a faster drive, and back in the day we used to put the root mount on a slow disk, and have a fast big data disk which is better for large files. I think an option to prevent tmpfs from getting shifted to swap (or disk) at all would be great.
MrDrMcCoy 2y ago
Not true if you enable zswap. The pages stay compressed in a RAM pool, and are only sent to the real swap on disk in their compressed states when that gets full. This significantly reduces I/O overall.

probably_wrong 2y ago

I've had cases where /tmp was full, usually by some runaway program that didn't clean up properly. The first indicator is usually that Bash auto-complete fails, followed by no one being able to SSH into the machine. I suppose mounting /tmp in RAM means this will happen more often (as RAM is usually smaller than hard drive space), but I don't see this becoming a giant issue. Now, auto-cleaning /var/tmp... that's going to cause SO MUCH data loss across people I know. I see a parallel with keeping files in your Desktop: yes, that's not what it's there for and ideally you'd store things properly, but you don't go around deleting people's documents just because you don't like it! Time to start sending warning E-Mails, I guess.

camel-cdr 2y ago
I quickly ran a backup just now, but I would've been one of the people slightly effected. I symlink some of the desktop cache files to /var/tmp, but since that never got deleted for me (on Debian and Manjaro) I also started linking things like my browser profile there. I kind of knew that /var/tmp may not be the correct folder for it, but if it works, it works you know. A bit of background on my setup, for why I even want to create such symlinks. My home folder is on an automatically mounted USB stick that I transfer between systems (laptop and desktop). On shutdown, I rsync the home folder to a local backup folder, which gives me a small distributed backup system. Using the same home directory between systems with different distributions and CPU architectures (I'm using the pinebook pro arm laptop) works surprisingly well. But I'd rather not stress the USB stick with a bunch of frequently accessed cache files, hence the symlink. I end up also symlinking the browser profile, because that caused version incompatibilities between systems, and I'm ok with having local browser settings/history on each device.
- somat 2y ago
  I sort of do the same thing, See, I like my homedir on a nfs share. (my philosophy is build one really good drive, raid, backups etc, then everything can use that, rather than try and put a good drive into everything) However there is stuff I don't really care about but would like to be fast and don't want eating my bandwidth, caches mainly, Now unlike you I tried to stay out of tmp so I made a /var/home/ on a fast local drive that vaguely mirrors /home and symlink the caches into it. That way it makes a good dedicated space for when I do want a fast local filesystem. As an antidote I had a hard time for a few years after I stopped using irix, I wanted(or at least my fingers wanted) the home directories to be under /usr/people

aftbit 2y ago

The discussions about swap in the LWN comments are interesting. I wasn't aware that at the "swap should be 2x RAM" tip was actually a hard requirement at one point (allegedly around Linux 2.4). I also wasn't aware that common recommendation was to run with swap again. I have some systems (usually VMs) where RAM is much bigger than the root disk. For example, 500+ GiB of RAM and only 100 GiB of disk. I have other VMs where the disk is orders of magnitude slower than the RAM (e.g. EBS on AWS EC2). I wonder what I should be doing for swap and vm.swappiness. Usually I just run with either no swap or a tiny 4 GiB swap file on /.

lionkor 2y ago
On real machines I run with a super low swappiness of 1-5 or so, which effectively means it will always use RAM, basically until its too late. That way its difficult to accidentally get OOM killed, instead everything just slows way down when swap gets involved when RAM is full.
- IshKebab 2y ago
  Yeah the trouble is in my experience it slows down to the point that the system is unresponsive and you have to reboot anyway. I don't think Linux has a good answer to RAM management other than "buy lots and lots of RAM" (I already have 32GB and it's nowhere near enough). I wish it worked like Windows - I've never had to reboot due to lack of RAM there, and even when the system is unresponsive ctrl-alt-del is very reliable.
  - dspillett 2y ago
    I've had Windows hang due (apparently) to OOM before now, most recently last week: already low on free memory due to other things, a runaway chrome tab chef through a huge pile of memory overnight. Come morning everything was at a crawl (task manager responded quickly but everything else took an age to register any event like a click or keypress. Bringing up chrome's task manager, sorting by RAM use, and navigating to the top of the list, to find the problem, took several minutes. Switching to that tab hung everything, even task manager. This was running in a VM so I could see from the host that the OS has hung: practically no CPU or IO use, what little there was was likely just "background noise" from hyper-v, also not even the simplest service accepted TCP connections nor would it respond to ping. Left it like that for tens of minutes to see no change, so resorted to a hard stop & start. It happens, albeit quite rarely.

bdjsiqoocwk 2y ago

Very OT, but I don't know where else to turn to because the Reddit community has been of no help. I used i3 and I absolutely love the way it feels. However I would like to configure it in a way that I can press a button and every app turns into dark mode. My main apps (Firefox, vscode) have an option to say "use system theme" i.e. if the os is dark, theme this app dark. Great! The problem is I don't know how to set the system theme. And every time I've asked around, I see people respond with GTK, QT and what not. I don't have those, I have i3. Help?

Arnavion 2y ago
What those people told you is correct, and "I don't have those, I have i3" is incorrect. Stop ignoring them.
- bdjsiqoocwk 2y ago
  I'm not ignoring. I still don't know how do I enable dark mode. If you have the answer, would you kindly help?
  - singron 2y ago
    i3 is just a window manager. It's not a UI toolkit. It doesn't control how apps render UI. GTK and QT are UI toolkits and do control how apps render UI. Your apps will use GTK and QT even if you use i3 to manage the windows. You might be confusing GTK with Gnome and QT with KDE, each of which has its own window manager.
    - smegsicle 2y ago
      so you're saying to get gtk apps to switch to dark mode, you'd find the gtk setting for dark mode? and the same for qt?
      - viraptor 2y ago
        Yes, for example check "gsettings set org.gnome.desktop.interface gtk-theme" for the gtk apps.

pantalaimon 2y ago

I don’t like it, I tend to use /tmp for large files or directories that are just that - temporary. Now they will either fill up my RAM or require a large swap partition (which I usually don’t have as it’s otherwise wasted space). I really like making /tmp the default destination for downloads, so either I need the file and move it elsewhere, but usually it’s an archive and I just want a file from it. Saves me from an ever growing Download folder. Those files are most dispensable and should not consume precious RAM. Some file systems are even adding specific tmpdir support where fsync() is turned into a noop. So they have all the advantages of tmpfs without eating into precious RAM/Swap.

stouset 2y ago
It's a default. You can change it.
- pantalaimon 2y ago
  Only on my personal machine. If I’m logged in elsewhere and keep my habit of working on large files in /tmp, I will be in for a bad surprise
  - stouset 2y ago
    So… don’t keep large files you want to control the lifecycle of in directories you don’t own? If you care about it, stop putting it in /tmp. You were always setting yourself up for a bad surprise by doing this, and now you’re surprised?
    - pantalaimon 2y ago
      I might download an ISO or check out a repo I want to build just once. Or copy some (large) files there because I run a script on them and persevere the original in case something goes wrong. I don’t care about those files once I’m done with them - so far they would only be gone with a reboot, which aligns well with my definition of done.

rwmj 2y ago

What's the point of putting /tmp in RAM when a competent disk-backed filesystem will do that with the most heavily used files anyway?

kasabali 2y ago
Change for the changes sake, of course.
pjerem 2y ago
You gain writing cycles that are not going to wear out your SSD for files that are going to be erased anyway.
silisili 2y ago
It's A) much faster, B) causes less wear, and C) automagically cleans itself, so to speak.
- pantalaimon 2y ago
  What about tmpdir as proposed by bcachefs? [0] That keeps the file in the page cache until it’s evicted, but instead of being written to swap it’s written to the fs. With the swap partition usually being quite small and the fs today being all the storage there is on a personal machine. [0] https://bcachefs.org/Roadmap/#tmpdir_support https://bcachefs.org/Roadmap/#tmpdir_support
  - arp242 2y ago
    Well, as I read that page it doesn't actually exist (yet), so that rather makes it a hypothetical at this point. Might be interesting in the future, but not today.
  - MrDrMcCoy 2y ago
    It's a neat idea, but I doubt it'll take off. Swap with zswap as a backing for tmpfs should be plenty for the time being.
2y ago

dur-randir 2y ago

[flagged]

dopylitty 2y ago

I believe I speak for all when I say I keep all my most important files in /tmp and ~/Downloads

somat 2y ago
Doing tech support for an office there is always that one guy who keeps his files in the windows trash. No I don't know why either, while not the stupidest thing I have seen, it comes close.
- john2x 2y ago
  It’s easy to find. It has a unique icon and everything. It even has a dedicated shortcut to move files to it. Why would you not use it?

camel-cdr 2y ago

Is there a easy/non hacky way to configure /tmp to only delete files on regular shutdown? I sometimes have the occasional crash, and have been bitten by doing some temporary work in /tmp before such a crash 2-3 times.

silisili 2y ago
You could do this pretty easily I think with systemd, it has a shutdown target that covers reboots and poweroffs. It would of course meaning not having tmp in RAM which is pretty common these days.

hsbauauvhabzb 2y ago

In the article there’s some mention of the implications of ram and swap - this has caught me before - if you wget an iso to /tmp, you may be consuming more ram than expected. And sure, that’ll get swapped out to disk, but that might be unexpected if you’re intending on using ram for virtual machines etc, you may end up OOM because of this behaviour. I did this on Fedora, and it left a bad taste in my mouth.

o11c 2y ago

/tmp on tmpfs is fine. /var/tmp being cleaned on boot is probably fine despite contrary standards in the past. But automatically deleting files - in either of those - while the system is running is going to break all sorts of things. As a random example, `chromium --temp-profile` will have half the profile deleted (since some particular files aren't accessed frequently) while the browser is running. This looks designed to cause system-level UB. Note that locks on directories are pretty rare; locks on a file within the directory are the de facto standard, on the assumption that only cooperating programs will access them.

lifthrasiir 2y ago
Indeed. I'm much more worried about partially deleted files in `/tmp` than the fact that files in `/tmp` do eventually get deleted.
dheera 2y ago
> But automatically deleting files - in either of those - while the system is running is going to break all sorts of things. Detect the process that created a file and delete it 24 hours after the process ends.
- jgalt212 2y ago
  Thanks for the homework assignment. The entire value proposition of tmp is there is no homework to do later.
- leni536 2y ago
  Chrome is multi-process, isn't it?
- blucaz 2y ago
  Or what about, delete it after 10 days it was last accessed (regardless of whether for read or write)? Hint: that's already how tmpfiles.d works
- o11c 2y ago
  That will fail badly with multi-process programs, which includes the example of browsers, and many others (databases anyone?).

throw0101c 2y ago

From FHS: > The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp. > Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp. * https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.htm... IRIX docs: > The directories /usr/tmp.O, /var/tmp, and /var/spool/uucppublic are public directories; people often use them to store temporary copies of files they are transferring to and from other systems and sites. Unlike /tmp, they are not cleaned out when the system is rebooted. The site administrator should be even more conscientious about monitoring disk use in these directories. * http://rsusu1.rnd.runnet.ru/sgi/advanced/ch8.html http://rsusu1.rnd.runnet.ru/sgi/advanced/ch8.html From FreeBSD 1.0 (July 1991): /var […] tmp/ temporary files not removed between system reboots vi.recover/ recovery files for the vi(1) editor * https://man.freebsd.org/cgi/man.cgi?query=hier&sektion=7&manpath=FreeBSD+1.0-RELEASE https://man.freebsd.org/cgi/man.cgi?query=hier&sektion=7&man... This is also true for Solaris, which I used to admin many moons ago. So I'm not sure where the idea that /var/tmp gets cleaned on reboot came from since I have always understood it to be fairly static.

SoftTalker 2y ago
Every unix does its own thing, you just have to know your system. In OpenBSD, /var/tmp -> ../tmp and /tmp is cleaned periodically and not preserved across reboots, but there are some specific exceptions and you have to dig into /etc/daily and /etc/rc scripts to know what they are.

pledess 2y ago

The essence of the problem is that there's no standard pathname for a personal directory that's guaranteed to be on local disk, even if $HOME isn't. Consequently, people have relied on /var/tmp/$USER for this. There are realistically affected users who can't change the new defaults. Cleaning up /var/tmp on a timer is relevant to this academic environment (desktop-based research computing): 1. Each Debian machine is used by only one graduate student, but students do not have root access. 2. Today, /var/tmp is the only persistent local directory where the student has write access ($HOME is on a network filesystem backed up by the university). 3. Within the student population, there is strong institutional memory that /var/tmp isn't backed up by the university and isn't extremely robust (e.g., RAID), but also that nothing there is automatically deleted. 4. Students use /var/tmp for hundreds of Gb of data from simulations that take days or weeks. $HOME is too small and too slow for this. 5. In practice, less than 1% of students lose data through disk failure, accidents, etc. 6. A much larger fraction of students will lose data when sysadmins, who didn't get the memo about the /var/tmp change and thus haven't addressed the ingrained institutional memory, deploy new Debian machines. 7. Some of the students who lose data won't graduate on time.

kbenson 2y ago
> The essence of the problem is that there's no standard pathname for a personal directory that's guaranteed to be on local disk, even if $HOME isn't. Consequently, people have relied on /var/tmp/$USER for this. There are realistically affected users who can't change the new defaults. How is that not a site specific problem they introduced? There's no standard pathname because there are valid reasons why you want to have nothing on the local system, such as when it doesn't have a local disk. If you (read as "the admins") have configured the system where there's very few acceptable locations to store local data, and that's a specific need, then it's up to the admins to provide a solution to the problem, not the Debian distro, which is flexible enough to handle this fine. It's not that hard to create your own location for data if you need to, and symlink to it from other locations if required. Need a /tmp/$USER to be a local disk location and /tmp is a ramdisk? Create a script that sets up the correct local location and created a symlink to it in /tmp and make sure it's run on boot and maybe once daily. Both cron and systemd solutions could work for this. Worried that user tmp files will be cleaned out when they shouldn't be? Put in the correct exceptions for tmpwatch or whatever debian uses, or disable that service. Not only is this not rocket science, it's literally the job of the admins that design the OS deployment so that it works for the intended use cases.

throwaway984393 2y ago

I find that, unless there's an extremely necessary reason, it's almost always bad to break backwards compatibility. If there's any concept whatsoever of continuity between major releases, backwards compatibility should be the default, with changes being options. Naturally this leads to more difficulty in testing and maintenance over time. But that extra work pays for the benefit of having a very long lived product and compatibility with past integrations. At the end of the day you have to decide if you're building a product to be easier for the users, or the maintainers. Personally I'm on the side of the users.

dekhn 2y ago

I really dislike people using the "I have an inflexible scientific code that needs /var/tmp to be disk and persisted forever" argument to keep things the way they are. Debian's user base is far larger than a few inflexible codes, and it's straightforward to change the default.

wang_li 2y ago
Code and scripts should be well behaved and clean up after themselves. There’s zero reason to periodically go in there and wipe stuff out. Especially when some file systems don’t have a creation time attribute in the on disk inode and some archiving tools preserve the mtime when unpacking. A newly placed file can already be five years old. Also the tone of some of the included quotes is so offputting. Their statements and arguments for this change don’t even acknowledge the fact that there are different views on this. This change comes across as progress for progress’ sake. Makes me want to make a 500TB /var/tmp and never delete anything.
- Izkata 2y ago
  > There’s zero reason to periodically go in there and wipe stuff out. I swear I remember back when I first switched to linux (Ubuntu) back in the late 2000s, this was how it worked: Instead of a tmpfs or automated wiping on boot, a system crontab entry that would use "find" to delete files last accessed more than some time ago (a day? a week?). Except for the risk of filling the disk if files are created too quickly, this would seem to be the best of all worlds to me - stuff can't stick around forever unless it's constantly being used. A download you access once would stick around for a day, while a heavy project that's using /tmp/ would stick around for the week or month you're using it, even across reboots, then get deleted later.
alextingle 2y ago
> it's straightforward to change the default. Care to share? Looking at https://systemd.io/TEMPORARY_DIRECTORIES/ https://systemd.io/TEMPORARY_DIRECTORIES/ and I don't see any description of how to change the default behaviour dictated by systemd. How do I disable the automatic file reaping? How do I configure the maximum age of temp files? Neither are mentioned. The bulk of the page is just a long list of passive-aggressive suggestions about how users are doing things wrong.

LooseMarmoset 2y ago

I have always assumed that /tmp means "temporary". I mean, it's right there in the name. So, a move to tmpfs means "automatic cleanup" to me, which seems just fine, and worth doing for that. If we're doing because the systemd maintainers say "we have to do it because systemd", though, well... How long till the systemd guys make package dependencies and installation as a service? You know, sponsored by the IBM/Redhat team, and signed by Microsoft? signed, a Devuan devotee

tristan957 2y ago
systemd is a project which provides building blocks for an operating system. PID 1 is just one building block. Lennart has said this since at least 2013. How the systemd naysayers haven't understood this in at least 11 years, I'll never understand.

skissane 2y ago

I wish Linux (and other Unix-like systems) had an API to let you create named temporary files which are automatically deleted - by the operating system - when a process exits. If you create an anonymous temporary file, then it will be deleted when the last file descriptor to it is closed-but anonymous temporary files are difficult to use (even given access via /dev/fd aka /proc/self/fd). You can delete it using atexit() but that doesn’t get run if the process terminates abnormally (core dump, kernel panic, kill -9, power outage, etc) Maybe something like a pidtmpfs where the top-level directories are pid numbers, you can create any files or directories you want under them, but it all disappears as soon as the process with that pid exits. Actually, pids are a bad idea due to pid reuse, you want something like a process serial number or a process UUID which doesn’t get reused. Another somewhat more flexible idea would be that you can create arbitrary top-level directories, but they - and all their content - are automatically deleted as soon as the last open fd to them is closed. That way you could have multiple processes sharing a temporary workspace, and the workspace could survive the failure of any one of them, but if they all fail it gets deleted

pram 2y ago
PrivateTmp in systemd does this.
- skissane 2y ago
  Unfortunately it only works for systemd units, as far as I am aware. Consider this use case: I have a test program which executes some unit tests, it creates some temporary files. I want the temporary files it creates to all be removed when it exits, even if it core dumps. But while it runs, I want those files to easily be accessible to subprocesses it spawns. I don't think systemd addresses this, because my unit test runner isn't going to be a systemd unit. So really I was talking about a generic facility an arbitrary program could use, not just something limited to systemd units only.
  - Wowfunhappy 2y ago
    > Consider this use case: I have a test program which executes some unit tests, it creates some temporary files. I want the temporary files it creates to all be removed when it exits, even if it core dumps. But while it runs, I want those files to easily be accessible to subprocesses it spawns. For this precise use case, what if you deleted the last run's temporary files at the start of the test program?

aidenn0 2y ago

> Sam Hartman noted that ssh-agent created its socket under /tmp, but it would be better if it respected the $XDG_RUNTIME_DIR setting and created its socket under /run/user. Boccassi agreed and said that he had filed a bug for ssh-agent. Richard Lewis pointed out that tmux stores its sockets in /tmp/tmux-$UID, and deleting those files might mean users could not reattach to a tmux session that had been idle a long time. Boccassi suggested that using flock() would be the right solution to stop the deletion, and said he had filed a bug on that as well. Ah, yet another group of Linux users looking to get ssh to adopt the XDG specification. Moving ~/.ssh to ~/.config/ssh has been repeatedly requeseted. XDG_RUNTIME_DIR is going to be even harder because it can be nonexistent on BSDs.

m463 2y ago

I'm annoyed that it is getting harder and harder to find what physical filesystems are on a system. My goto commands "df -h" and "mount" are cluttered with all kinds of ephemeral filesystems, with no easy way to filter (say, a one-character flag). lsblk is close but .. lvm and snaps.

ssl-3 2y ago
On my main-driver desktop box that I hamfistedly switched over to Void Linux (on a ZFS root, even) a couple of months ago: The output of df -h looks pretty sane and understandable. I see some entries for /dev and /run and /, some stuff for EFI, a bunch of mounted ZFS datasets, and it's all very readable with no line noise in any column. --- Now, that said: I have some docker containers. My own previous goto command of mount reports a complete clusterfuck, and all of the clusterfucked lines are due to docker doing docker stuff. I don't know how things like 4UYSHHPFBZQNFZ9Z698JDLUZWJ, LK33RZTN5ZNFGPJNDUHM0HTSD1, 2G0A4YYUVCMP9HZSM5UXOJW0BX, ZH29C5YNZHJ22QMY63EWV5RF3P, and 32XOCXBUY41QQJTPPA8HE6EVZ6 add any coherency or clarity[1], but I assume that since the computer quite easily knows what this shit means then it needn't be bothered with dumbing it down so that a human can parse it in any sort of memorable or repeatable or communicable fashion. (Which is, of course, bad behavior on the part of the computer. A UUID is also awful, but at least it has some punctuation so that it can have some cadence if it must be dealt with as-is. It's like we learned nothing from DNS[2], or as if translation layers can't exist even within a filesystem[3].) 1: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2016788/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2016788/ 2: https://datatracker.ietf.org/doc/html/rfc1035 https://datatracker.ietf.org/doc/html/rfc1035 3: https://linux.die.net/man/1/ln https://linux.die.net/man/1/ln

juliangmp 2y ago

>The knobs to control how /tmp is mounted, and the handling of temporary files, are part of systemd. Huh? Someone explain this to me, wasn't fstab the mechanism to define things like this? Why does my init/service manager need to mess with it???

zbentley 2y ago
Systemd has managed mount points on systems where it runs for a long time. It provides mount units an alternative to fstab mount directives, which offers some advantages (including parallelism of at-boot mounting, granular mount dependencies for services, automatic runtime mounting and unmounting) and disadvantages (harder to view at a glance than fstab, more complex). What’s more, on systemd systems, fstab is dynamically converted into native systemd mount units at boot, so in many cases fstab is purely a facade/compatibility shim over systemd doing all the mounting anyway. While not terribly prescriptive, “man systemd.mount” recommends /etc/fstab be used to manage “mounts for humans” due to its simplicity and accessibility. So it doesn’t seem like fstab is considered legacy or deprecated by systemd; rather, this seems like more of a porcelain/plumbing distinction.

M95D 2y ago

Programmers and sysadmins should keep track of their garbage, not break all of our systems just so they can get lazy.

bayindirh 2y ago
A competent sysadmin not only tracks their garbage, but others' garbage as well. On the other hand, a sysadmin strives to be lazy, not by postponing problems, but solving them the appropriate way, and preventing it from happening again.
- M95D 2y ago
  > but others' garbage as well. No! That's what quotas are for. Everyone should keep track of it's own garbage.
  - bayindirh 2y ago
    Who says I don’t use quotas? I just routinely check how everyone is doing, and what my server is doing. That’s all.

bionade24 2y ago

Hopefully Ubuntu will align with this decision, so that MATLAB is finally forced to fix their shitty software. (I am aware that you can set the TMPDIR as an env var)

ericbarrett 2y ago

When I started in tech I worked for a storage vendor’s tech support. One of my first big cases was troubleshooting why a customer’s files older than a week were disappearing. Given the topic, I’m sure you can guess—they had it mounted under /tmp and the cleanup script was doing its thing. Hopefully the new Debian version of this script is a bit smarter!

jimbobthrowawy 2y ago

I only learned that disk backed /tmp/ wasn't the default a couple of months ago after mainly using ubuntu for years and wondering why I was quickly running out of ram on a fedora machine.