Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Similarly, I’m following the thread for a couple of days now, and wondering about its implications.
When I consider server scenarios, pushing /tmp to RAM looks highly undesirable from my perspective. All the servers I manage use their whole RAMs and using the unused space as a disk cache is far more desirable than a /tmp mount. When servers are virtualized, RAM is at premium, and a disk cache is way more usable rather than /tmp in the RAM.
The other scenario I think is HPC, where applications use all the RAM available, squeezing the hardware dry. Again, /tmp in the RAM is very undesirable, because /tmp/$USER is also heavily used and an OOM situation creates a lose-lose situation where you either delete runtime files, or lose the executing job, which results in job failure in any case.
On the other hand, I personally use my desktop computer as a development workstation and use tons of RAM either with software or with VMs. Again a /tmp in RAM is an inferior scenario to my current setup.
The only useful state where /tmp is in RAM is single board computers where temp is both lightly utilized and maximizing SD/eMMC life is important. These systems even mount /var/log to a tmpfs and sync on boot/reboot/shutdown, reducing flash wear.
Deleting /var/tmp has the same problems since long running tasks on the servers might need a file once in a month, but it can be crucial for functions of the software.
I can’t see any scenario where these two are useful in typical or niche installations of Debian.
FWIW, RedHat family doesn’t mount /tmp as a tmpfs on its default installation.
Cheers,
H.
> On 7 May 2024, at 12:42, Peter Pentchev <roam@ringlet.net> wrote:
>
> On Tue, May 07, 2024 at 10:38:14AM +0200, Carsten Leonhardt wrote:
>> Luca Boccassi <bluca@debian.org> writes:
>>
>>> Defaults are defaults, they are trivially and fully overridable where
>>> needed if needed. Especially container and VM managers these days can
>>> super trivially override them via SMBIOS Type11 strings or
>>> Credentials, ephemerally and without changing the guest image at all.
>>
>> That argument goes both ways and I prefer safe defaults. What
>> you/upstream propose are unsafe defaults, as was shown by several
>> comments in this thread. Whoever wants the unsafe defaults of deleting
>> old files and risking OOM situations can than "trivially and fully
>> override" the safe defaults.
>
> So I've been wondering for a couple of days now, following this thread...
> ...would it be a good idea to make this a debconf prompt, high priority,
> default "yes", so that it is activated on new automatically installed
> systems, but people who upgrade their current Debian installations can
> choose to keep the old behavior?
>
> I do realize that more debconf prompts are not always desirable, and
> such decisions must be taken on a case-by-case basis, so... yeah.
>
> G'luck,
> Peter
>
> --
> Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com
> PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
> Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Reply to: