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]
> 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
Reply to: