3 ms·

/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

by 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?).
b112 2y ago
/tmp on tmpfs is fine. Hanging my comment here. Sorry to slap it into your universe. My knowledge says... is it fine? My RAM is for applications, and I buy RAM accordingly. Most in this discussion seem to miss something quite vital and important. Linux is excellent at caching most-needed, most-used data in RAM, eg buff/cache in 'top', and that should be given higher priority than some temporary file a user might slap in /tmp/. 50% of my RAM, randomly flushing out buffers and cache! Buffers and cache, which stores commands I use frequently, libraries often used by applications, and so on! Any server that is reasonably loaded, will show RAM fully used by buffers/cache, excluding active RAM requirements. Now I'm to give 50% of this up, having those buffers/cache flushed for... someone unarchiving a tarball?! And my swap file, something for emergency application RAM usage, now being stolen by /tmp. We're basically taking the most expensive storage space on a system, RAM, and relegating it to... a few log files, someone untarring software, and also... Hard limiting its size to RAM requirements?! This is sheer madness. It smacks of people with desktops, with enormous amounts of free RAM, making decisions for servers. This change is bad. Thoughts: * It is not relevant what systemd does, endless things in Debian and other distros diverge from what systemd does * Debian isn't aligning with 'other distros' when doing this, as there isn't a consensus here. Debian isn't some hold out, in fact there are far, far fewer installs elsewhere doing this. * Stealing my RAM for transient files is dumb
- zepolen 2y ago
  Not to mention if you did have a large tmp file that you actually want to persist to a different directory that is on disk you now have to wait for the damn file to be copied from memory to disk vs a single atomic rename operation, this can have major implications depending on the context.
  - guappa 2y ago
    Rename doesn't work across filesystems. You just create a new file and do a regular copy.
- bildung 2y ago
  > Now I'm to give 50% of this up, having those buffers/cache flushed for... someone unarchiving a tarball?! Nope, unarchiving tarballs doesn't write the tarball content to /tmp. > It smacks of people with desktops, with enormous amounts of free RAM, making decisions for servers. * Servers usually have way more RAM than desktop devices? Unless you mean VMs, in which case the VM can't decide what device /tmp lies in anyway. * in any case it will be trivial to just not use it for your servers, if you prefer /tmp to be on disk. Just like I already used tmpfs for 2 decades in Debian, it is a single line in /etc/fstab either way.

by o11c 2y ago

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?).

b112 2y ago

/tmp on tmpfs is fine. Hanging my comment here. Sorry to slap it into your universe. My knowledge says... is it fine? My RAM is for applications, and I buy RAM accordingly. Most in this discussion seem to miss something quite vital and important. Linux is excellent at caching most-needed, most-used data in RAM, eg buff/cache in 'top', and that should be given higher priority than some temporary file a user might slap in /tmp/. 50% of my RAM, randomly flushing out buffers and cache! Buffers and cache, which stores commands I use frequently, libraries often used by applications, and so on! Any server that is reasonably loaded, will show RAM fully used by buffers/cache, excluding active RAM requirements. Now I'm to give 50% of this up, having those buffers/cache flushed for... someone unarchiving a tarball?! And my swap file, something for emergency application RAM usage, now being stolen by /tmp. We're basically taking the most expensive storage space on a system, RAM, and relegating it to... a few log files, someone untarring software, and also... Hard limiting its size to RAM requirements?! This is sheer madness. It smacks of people with desktops, with enormous amounts of free RAM, making decisions for servers. This change is bad. Thoughts: * It is not relevant what systemd does, endless things in Debian and other distros diverge from what systemd does * Debian isn't aligning with 'other distros' when doing this, as there isn't a consensus here. Debian isn't some hold out, in fact there are far, far fewer installs elsewhere doing this. * Stealing my RAM for transient files is dumb

zepolen 2y ago
Not to mention if you did have a large tmp file that you actually want to persist to a different directory that is on disk you now have to wait for the damn file to be copied from memory to disk vs a single atomic rename operation, this can have major implications depending on the context.
- guappa 2y ago
  Rename doesn't work across filesystems. You just create a new file and do a regular copy.
bildung 2y ago
> Now I'm to give 50% of this up, having those buffers/cache flushed for... someone unarchiving a tarball?! Nope, unarchiving tarballs doesn't write the tarball content to /tmp. > It smacks of people with desktops, with enormous amounts of free RAM, making decisions for servers. * Servers usually have way more RAM than desktop devices? Unless you mean VMs, in which case the VM can't decide what device /tmp lies in anyway. * in any case it will be trivial to just not use it for your servers, if you prefer /tmp to be on disk. Just like I already used tmpfs for 2 decades in Debian, it is a single line in /etc/fstab either way.