Hakan Bayındır <ha...@bayindir.org> writes: > The applications users use create these temporary files without users' > knowledge. They work in their own directories, but applications create > another job dependent state files in both /tmp and /var/tmp. These are > different programs and I assure you they’re not created there because > user (or we) configured something. These files live there during the > lifetime of the job, and cleaned afterwards by the application.
Then someone should fix those applications, because that behavior will result in user data loss if they're not fixed. However, first one should check whether the applications are just honoring TMPDIR or equivalent variables, in which case TMPDIR on batch systems often should be set to a user-specific or job-specific persistent directory for exactly this reason. That way you can use a user-specific cleanup strategy, such as purging that directory when all of the user's jobs have finished. I understand your point, which is that this pattern is out there in the wild and Debian is in danger of breaking existing usage patterns by matching the defaults of other distributions. This is a valid point, and I appreciate you making it. My replies are not intended to dispute that point, but to say that the burden of addressing this buggy behavior should not rest entirely on Debian. What the combination of batch system and application is doing is semantically incorrect and is dangerous, and it really should be fixed. Even if Debian changes nothing, at some point someone will deploy workers with a different base operating system and be very surprised when these files are automatically deleted. We were automatically cleaning /tmp and /var/tmp on commercial UNIX systems in 1995 and fixing broken applications that didn't honor TMPDIR. This is not a new problem. Nor is having /var/tmp fill up and cause all sorts of system problems because someone turned off /var/tmp cleaning while trying to work around broken applications. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
