There is a new trend that I find slightly alarming: applications deleting their temp files as soon as they are open. Two of the culprit that came to my attention recently are GNU coreutils mktemp and MariaDB.

I understand the objective, they want to leave the environment clean even in the case of a crash, a digital "Leave No Trace" of sort. But I think this is wrong.

It is wrong because it makes diagnosticating both application and filesystem problems difficult.If you have a hunch that an applications is having filesystem space issue, you usually use "normal" filesystem tools such as "ls" and "du" to quickly confirm your intuition. You don't usually take "strace" and "lsof" out of the toolbox right away, using them for harder issue. It is wrong because if you delete all your temp files, there is no longer any way to quickly find out who's using all the space in a given filesystem, "lsof |grep deleted" only shows you a list of files and their size, you have to do the calculation yourself. The convenience of "su -sh * |sort -h" is now gone.

It used to be that applications caught signals and deleted their temporary files before terminating. When killed with SIGKILL or when crashing, temporary files would stay on the filesystem, but in /tmp, and both users and sysadmins knew how to deal with them. If anything, finding large or numerous old files in /tmp used to be a symptom that something was going on and needed to be addressed. The convention was that if you write a file in /tmp, it can be deleted without adverse effect on your apps, therefore leaving files in /tmp after a crash was never really an issue.

I'd like to have some feedback from this community. Am I just old school, or do you guys share the same concern? As LOPSA, can we raise the awarness around the issue? I'm thinking of writing a blog about it myself, but I'm wondering if we can do something with more visibility.

--
Yves.
_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

Reply via email to