On 4/4/21 6:06 PM, Dave Howorth wrote:
On Sun, 4 Apr 2021 16:25:14 -0400 DennisG <dwgallien@gmail.com> wrote:
On 4/4/21 1:35 PM, Carlos E. R. wrote:
On 04/04/2021 19.10, DennisG 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
On 4/4/21 7:56 AM, Dave Howorth wrote: 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. Err, I'm sitting here typing this mail in an X session:
# ls -l /tmp total 4 -r--r--r-- 1 root root 11 Mar 17 14:30 .X0-lock drwxrwxrwt 1 root root 4 Mar 17 14:30 .X11-unix srwxr-xr-x 1 dhoworth users 0 Mar 17 14:30 .pcmanfm-socket--0-dhoworth srwxr-xr-x 1 dhoworth users 0 Mar 20 11:19 OSL_PIPE_1000_SingleOfficeIPC_2c139c358aa808ba56150309b273129 drwx------ 1 dhoworth users 64 Apr 4 21:09 claws-mail-1000 drwx------ 1 dhoworth users 22 Apr 4 21:12 firefox drwx------ 1 dhoworth users 20 Mar 17 14:30 ssh-t2p7Ucvz2L46 drwx------ 1 dhoworth users 20 Mar 17 14:30 ssh-tOiEo97kMLfN drwx------ 1 root root 6 Mar 17 14:30 systemd-private-8f940ab862e84761900565a3bdeaae33-apache2.service-mh7U89 drwx------ 1 root root 6 Mar 17 14:30 systemd-private-8f940ab862e84761900565a3bdeaae33-ntpd.service-oUZrzc drwx------ 1 root root 6 Mar 17 14:30 systemd-private-8f940ab862e84761900565a3bdeaae33-redis@default.service-r91TIl
No xauth files at all ????
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.
--dg
I have no idea. When I did my testing, I was looking only at the consequences of using different Type and Age parameters. I have noticed that running some apps results in an xauth* file (second type) being created but then deleted when the app closes, while others when run will have a file created but not deleted when the app is closed, and yet for others there is no new xauth* file created at all. And something periodically accesses or updates the file tied to the display. My wild guess is that this varies with the DE (I'm using KDE) and the individual programs. --dg