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 29 May 2024, at 17:33, Marvin Renich <mrvn@renich.org> wrote:
>
> * Hakan Bayındır <hakan@bayindir.org> [240529 07:51]:
>> On 28.05.2024 ÖS 8:16, Andreas Metzler wrote:
>>> On 2024-05-28 Luca Boccassi <bluca-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> wrote:
>>> [...]
>>>> - existing installations pre-trixie will get an orphaned tmpfiles.d in
>>>> /etc/ that keeps the existing behaviour unchanged (no cleanup of
>>>> /var/tmp)
>>> [...]
>>>
>>> Hello,
>>>
>>> I think it is bad choice to deliberately have different behavior for
>>> freshly installed and upgraded systems. Offering upgrades has always
>>> been one of the major selling points of Debian, and imho this
>>> implicitely includes that you do not get a worse or second class Debian
>>> installation when you upgrade it than if you installed from scratch.
>>>
>>> cu Andreas
>>
>> I'll kindly disagree here.
>
> While I agree with Andreas that having the same behavior for upgraded
> systems and new installations is generally better, I agree with you that
> in this specific case it is not the better choice.
>
>> I'd rather not have to go back to every system
>> and make sure that they all behave the way I want after doing a periodic,
> ^^^^^^^^^^^^^^^^^^^^^
>> completely boring "apt-get upgrade".
>
> You haven't specified what behavior you want. Is it the existing
> behavior or the new behavior? This thread is exactly about choosing
> between the two, and possibly between different behavior for new and
> existing systems.
Sorry, I thought that the sentence was self explanatory. Using English as a second language has its peculiarities. Let me explain.
1. For existing systems, I don’t want anything modified. Let it be Debian’s old defaults, or a custom config I made for that system. IOW, I want my old systems to have /tmp as a proper disk partition, and nothing to be cleaned periodically, or whatever I set to these systems.
2. For new installation, I’m fine with what Debian proposes. For clarity, I’m still against automated cleaning of /tmp and /var/tmp of the reasons I outlined before (tl;dr: Long running systems with seldom accessed but required files), but I’m fine with whatever Debian decides and ships. At most, I’ll configure the behavior I need, but I don’t expect it to be changed down the line by package updates.
Hope this clears this part.
>
> There are four combinations of old/new behavior and upgrading/new
> installation. Eliminating the obviously bad combination, we are left
> with three:
>
> A. Keep old behavior for both upgrading and new installations.
> B. Keep old behavior for upgrading, use new behavior for new installations.
> C. Apply new behavior for both.
As I aforementioned, I’m a proponent of “A”, but it’s not favored it seems. So, I want to drive the line at “B”. “C” can cause problems because a seasoned Debian install is probably old enough to attend school (i.e. 7+ years), and a ton of custom configuration is accumulated in /etc, ~/.local, ~/.config and elsewhere. Touching working systems and periodically deleting files out of nowhere can cause big headaches and worse.
> The new behavior is preferable for many use cases, but the old behavior
> is not a "BUG" that must be fixed. Debian has had the old behavior for
> a very long time.
>
> A number of people have spoken up on this list saying that they are
> relying on the old behavior, and that changing to the new behavior could
> potentially cause serious data loss.
I personally don’t rely on the old behavior, but I work with clusters, and as I detailed, some files can linger for a very long time before deleted. These are not bugs of these systems, it’s just a side effect of how clusters and long running jobs work. Also, RedHat and their derivatives behaves exactly the same as how current Debian behaves. /tmp is a partition (which we sometimes mount to a high speed NVMe RAID on multi-GPU systems), which is used for data exchange between processors, processes, etc., and these files live a pretty long life for longer jobs.
>
> Some people have stated an opinion that keeping upgraded systems in sync
> with the behavior of new installations is desirable.
>
> So to choose between A, B, and C, we must rank the following:
>
> X. desirability of new behavior
> Y. preventing data loss for an unspecified, but non-zero, number of
> existing systems
> Z. desirability of having upgraded systems match new installations.
>
> Both X and Z are primarily opinions with some (non-overwhelming)
> technical merit to each.
>
> Sufficient technical arguments have been provided on this meta-thread to
> support that Y is highly important and also more important than both X
> and Z. This means that choice C fails.
So yes, Y is very important for some (small in number, big in footprint) installations.
> If Z were more important than X, then the order of importance would
> become Y, then Z, then X, which would make choice A the winner.
>
> However, there have been no technical arguments whatsoever that Z is
> more important than either of X or Y, only a few personal opinions.
> And, from the discussion, the consensus appears to be that X is more
> important than Z, so the order is Y, then X, then Z.
>
> This gives us choice B as the wi
> nner.
This is where I can compromise, so this is what I tried to imply with the sentence you marked.
> It also looks like Luca Boccassi has already made the changes to effect
> choice B. Thank you, Luca!
>
> ,,,Marvin
Cheers,
H.
Reply to: