> 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. 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. 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. 3. Defend the system against forgetful users, who create files in /var/tmp/ but neglect to delete them when they're no longer needed. Unfortunately 2 & 3 cannot be mechanically distinguished, so even if you wanted to have separate policies for these two classes of files, it's not really technically possible. So upstream is optimizing for case (2), and suggests that /var/tmp/ be sort of reserved for programs and scripts that are aware of this policy, and users not manually create files there. I hope that's an accurate characterization. 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. Here are a couple cheap tweaks I'd suggest. My hope is that these would avoid some of the worst case scenarios discussed while still satisfying the goals 1/2/3 above, and being super easy to implement. - lengthen the reap time for /var/tmp/ to eight weeks, since Europeans often take six-week vacations. - make a "tempdir" command, philosophically similar to tempfile in debianutils, which creates a fresh directory in /var/tmp/ and drops the user into a shell with that as the current directory, directory flocked until that subshell terminates. Could give an optional directory argument to lock so you can get back into a directory, and maybe have options to run a program there before or instead of the subshell. - following a resume-from-suspend or boot, shut off the delete-old-files-in-var-tmp mechanism for a while, maybe eight hours or something like that. Maybe shorten the delay if it doesn't get to run across multiple resume-or-boot cycles for a week or two. - as discussed earlier, add /tmp/00-README and /var/tmp/00-README to explain this old-file-deletion policy