On 4/4/21 5:25 PM, Carlos E. R. wrote:
On 04/04/2021 22.25, DennisG wrote:
On 4/4/21 1:35 PM, Carlos E. R. wrote:
On 04/04/2021 19.10, DennisG wrote:
On 4/4/21 7:56 AM, Dave Howorth wrote:
On Sat, 3 Apr 2021 17:28:48 -0400 DennisG <dwgallien@gmail.com> wrote:
Just note however that there are programs which will put a file under /tmp that it will use as long as it is open but will not be protected from deletion If a program does that, then it should simply keep the file open whilst it is running. If it does that then it will continue to have access to the file even if it is deleted from the filesystem.
Maybe should, but not necessarily, will. X (and presumably, other programs) writes files to /tmp that are not protected. If deleted before it is replaced with a new file (I don't know what triggers that), the server crashes. I encountered this in tests using age "1h". So essentially, this calls for the same caution that is recommended with using e.g. r, R, or age zero - i.e., timing is critical.
Wouldn't those files have been accessed at least once during the current machine uptime?
The cleaning routine should not delete any file which has one of the three timestamps shorter than the current uptime.
You are quite right. Using the X server as an example . . .
There are 2 types of X files written to /tmp when the server starts, an xauth* which is tied to the display number and a differently formatted xauth* which is tied to some session activity. Since my last boot the former xauth* file has been renewed (i.e., same filename) several times, updating /all 3/ timestamps each time - the most current being ~3 hours ago. I have 4 files of the latter types, each created and accessed periodically since boot, with 1 having had all 3 timestamps updated ~5 hours ago.
Running systemd-tmpfiles with an age flag set to 1h, the xauth* file tied to the display was deleted, as were 3 of the 4 other xauth* files. Depending on the activity, when X found the files missing it created replacements, other times it locked the app and crashed the server. This can happen with other programs/apps, e.g. in one test I killed KDE and in another I killed Pulse.
Of course these are extreme examples. I added that remark to my post just as a clarification for the OP, in line with the wiki warning about not removing needed /tmp files while in a session, which can happen with the age flag set too short or worse yet, using zero. Unlikely, yes. But possible.
The problem (to me) seems that the age flag must be dynamically set to something larger than the current uptime, not a fixed value.
If we can not do that somehow, I prefer to leave the thing disabled.
Right. My solution was to add the exclamation point (d!) to /etc/tmpfiles.d/fs-tmp.conf and fs-var-tmp.conf, add --boot to systemd-tmpfiles-clean.service, and comment out OnUnitActiveSec in /usr/lib/systemd/system/systemd-tmpfiles-clean.timer. That cleans /tmp and /var/tmp with every boot. (I understand that you already know this, I'm just including the details for anyone who may later read this thread.) --dg