Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Mon, 6 May 2024 at 15:42, Richard Lewis
<richard.lewis.debian@googlemail.com> wrote:
>
> Luca Boccassi <bluca@debian.org> writes:
>
> > Hence, I am not really looking for philosophical discussions or lists
> > of personal preferences or hypotheticals, but for facts: what would
> > break where, and how to fix it?
>
> cleaning /tmp or /var/tmp: users may lose files if they dont realise a
> directory tmp can be cleaned without a reboot. something in /var/tmp
> that's been in there for 35 days before an upgrade might be deleted
> before the user reads the NEWS.Debian email, meaning they have no
> chance to react). Maybe you could postpone the very first deletion
> until after the next reboot?
>
> using a tmpfs: is there a risk of losing unrelated data due to more
> frequent OOM killing random other programmes due to /tmp using all the
> memory? is there a case to only use a tmpfs if the system has
> "enough" memory?
Again, those are all hypotheticals, and one can construct similarly
contrived thought exercises for most possible permutations of most
configurations, and the answer is always the same: customize the
configuration accordingly. Hence, not relevant right now.
What is relevant is: which packages, if any, or which DSA-owned
systems, if any, are actually affected and how?
Reply to: