4 ms·

/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

/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.
- stuaxo 2y ago
  If the system went wonky because the disk was full, then clearing this on boot might help me get to a working system.
- jraph 2y ago
  > 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. That's on them. I use /tmp like this, because I'm lazy and don't want to have to mess with a directory I need to routinely clean up, but I know that if the computer crashes, it's gone. That's on me. If you don't like this risk, you need to work in persistent storage. /tmp is for programs' temporary files. Manually using it like this is abusing it. That's fine, it doesn't hurt anyone beside the user doing it, but they need to bear the consequences of doing it.
  - Spivak 2y ago
    > If you don't like this risk, you need to work in persistent storage. Which is literally what /var/tmp is and what the parent is advocating for. However, clearing /tmp at boot is not the greatest technical choice. There's nothing really special about rebooting the system. The idea that files in /tmp are kept around for anywhere between minutes, hours, and days makes for bad policy which systemd-tmpfiles fixes quite elegantly. You shouldn't lose your temp file after 30 seconds because your machine lost power. You should be able to say "files created here are cleared after $short_time of inactivity."
    - semi 2y ago
      does inactivity mean writes? reads? stat() calls? IMO setting the expectation of 'wont survive a reboot' is more consistent. but even that fails with private tmp files that could be tied to ephemeral units
      - Spivak 2y ago
        mtime atime ctime? If it's good enough for logrotate it's good enough for /tmp.
crabbone 2y ago
> /tmp/ is the ram-backed version for small files Small you say? The block size in that device is the size of the memory page: 4K by default. That's 8 times the very typical 512b for persistent storage. I've been bitten many times when trying to start in-memory only VMs with a disk image that measured smaller than available memory only to run out of memory on boot :) Let's say it's not really for small files. It's for few files. ;)

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.

stuaxo 2y ago
If the system went wonky because the disk was full, then clearing this on boot might help me get to a working system.
jraph 2y ago
> 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. That's on them. I use /tmp like this, because I'm lazy and don't want to have to mess with a directory I need to routinely clean up, but I know that if the computer crashes, it's gone. That's on me. If you don't like this risk, you need to work in persistent storage. /tmp is for programs' temporary files. Manually using it like this is abusing it. That's fine, it doesn't hurt anyone beside the user doing it, but they need to bear the consequences of doing it.
- Spivak 2y ago
  > If you don't like this risk, you need to work in persistent storage. Which is literally what /var/tmp is and what the parent is advocating for. However, clearing /tmp at boot is not the greatest technical choice. There's nothing really special about rebooting the system. The idea that files in /tmp are kept around for anywhere between minutes, hours, and days makes for bad policy which systemd-tmpfiles fixes quite elegantly. You shouldn't lose your temp file after 30 seconds because your machine lost power. You should be able to say "files created here are cleared after $short_time of inactivity."
  - semi 2y ago
    does inactivity mean writes? reads? stat() calls? IMO setting the expectation of 'wont survive a reboot' is more consistent. but even that fails with private tmp files that could be tied to ephemeral units
    - Spivak 2y ago
      mtime atime ctime? If it's good enough for logrotate it's good enough for /tmp.

crabbone 2y ago

> /tmp/ is the ram-backed version for small files Small you say? The block size in that device is the size of the memory page: 4K by default. That's 8 times the very typical 512b for persistent storage. I've been bitten many times when trying to start in-memory only VMs with a disk image that measured smaller than available memory only to run out of memory on boot :) Let's say it's not really for small files. It's for few files. ;)