Hi, Quoting Barak A. Pearlmutter (2024-05-13 10:47:43) > > I'd like to hear some arguments *in favour* of making this change. > > Alignment with systemd-upstream, reduced package maintenance burden > > are two that I can think of, but perhaps I've missed more. These two, > > IMHO, are significantly outweighed by the risks. > Let me see if I understand the arguments being made in favor.
thank you, I'd also like to understand them. > 1. Compatibility with upstream. This means all the upstream logic is sort of > imported by reference, so the below is mainly the upstream logic, as I > understand it. Yes, I also think that there is value in doing the same thing that upstream or other distros are doing. There is a cost if Debian decides to deviate from what others decided to be the default. > 2. Defend the system against buggy programs that leave debris in /var/tmp/, > and against debris left there when programs are terminated prematurely. > These are programs which use /var/tmp/ internally, but not as part of > their API, so the user would have no particular way of knowing that they > are leaving things there, would have no particular reason to check for and > delete such files, and might not be able to easily recognize which files > should be removed. But I do not understand this as an advantage. In my mind it is quite the opposite. The buggy programs which leave files in /tmp will now have their bugs not noticed anymore because the files get cleaned up by systemd. On the other hand, we are now introducing new bugs in programs which should do an flock on the temporary directory but do not do so yet. Imagine I would not've read debian-devel. How would I as the mmdebstrap author have noticed that my tool as a user of /tmp should set up this flock? I imagine the bug report of somebody who has a weird problem with the chroot but somehow they are unable to reproduce it because it depends on the cleanup timing. Are the bugs we are introducing by regularly cleaning up /tmp not potentially super hard to diagnose and might thus just not get fixed? Is there an effort to go around and identify programs we ship with long lasting use of /tmp and is filing bugs so that they are performing an flock? And at the same time we are now ignoring the bugs in programs who leave files in /tmp and forget to clean them up. Is this not a disadvantage of this change instead of an advantage? > I looked at the upstream bug report > https://github.com/systemd/systemd/issues/32674 which suggests that deletion > of directory trees in /var/tmp/ be atomic, and trigger only when everything > in the tree meets criteria for deletion. I added a comment suggesting that > the policy be tweaked in two ways. (a) Use system-up time rather than > wall-clock time for measuring file age, to address the "suspending or > shutting down for over 30 days breaks running data processing scripts that > uses /var/tmp/ for intermediate files" issue. I sort of have an invariant in > my head, which is that suspending the computer doesn't break things, and also > the whole point of /var/tmp/ is that files there are preserved across boots. > And (b) check if a file is open by some process, the same way fuser(1) does, > and if so, don't delete it. Could also preserve directories which are the > current directory of some process, if you want to be even more user friendly. > > The only response I got was "don't use temporary directories for things that > you cannot afford to lose and recreate", which I don't really understand. > It's like saying "you should have good backups, so it's not a problem to just > delete anything in /home older than two days". Bottom line, it's not clear to > me that upstream has really thought this through with users in mind. I'd > suggest that Debian may wish to tweak the defaults on this stuff pretty hard > to be more user friendly. Thank you, the suspend issue is another issue that is created by this change. If we want to try and weigh cost against benefit, do the benefits really outweigh the cost? How costly is it to carry a patch in Debian and deviate from upstream versus all the problems that participants of this thread now listed? My gut feeling is, that the cost of these hard to debug problems is far greater than continuing to deviate from upstream and carry a Debian-specific patch, no? > - as discussed earlier, add /tmp/00-README and /var/tmp/00-README to explain > this old-file-deletion policy I think this is a really good idea. Thanks! cheers, josch
signature.asc
Description: signature
