Does systemd-tmpfiles --clean remove open files?
Environment
- Red Hat Enterprise Linux 7
Issue
-
Will
systemd-tmpfiles-clean.service
or manual execution ofsystemd-tmpfiles --clean
remove open files? -
In earlier versions of RHEL, when using
tmpwatch
to clean up files, the--fuser
option could be used to ensure open files wouldn't be used. Doessystemd-tmpfiles
have something like this? -
I'm planning to use tmpwatch's
--fuser
feature. Doessystemd-tmpfiles
support runningfuser
so that it won't delete any files which have an open file descriptor?
Resolution
-
When using
systemd-tmpfiles
to clean files based on age,1 each of the 3 traditional timestamps (atime, mtime, & ctime) are taken into account -
systemd-tmpfiles
does not provide a feature analogous totmpwatch --fuser
systemd-tmpfiles
does not check to see if a file is opened by a process
systemd-tmpfiles
only looks at the file timestamps2 -
Simply put, if an application reads from a file3 or writes to a file more often than the
tmpfiles.d(5)
age parameter, the file will not be removed bysystemd-tmpfiles --clean
-
Note also that the tmpwatch package (and thus
tmpwatch --fuser
) is still available in RHEL 7
-
That is, with
d
,D
,v
, orx
(seeman tmpfiles.d
) ↩︎ -
See this [systemd-devel] tmpfiles versus tmpwatch mailing list thread, in particular, the following quote from Lennart Poettering: "Nope, we do not support this, and it's unlikely we ever will. fuser is relatively expensive, since it iterates manually through all subdirectories of /proc to find open files. If the kernel had a better interface for this, that makes this less expensive, we might consider supporting that, but the iterating through /proc is simply too bad." Another user response: "tmpwatch's fuser feature is IMHO just a countermeasure for filesystems mounted with noatime in combination with wrongly behaving software which has long living processes opening files in /tmp. That's wrong by design." ↩︎
-
Assuming the relevant filesystem is mounted without the
noatime
option ↩︎
Diagnostic Steps
-
Example:
[root]# cat /etc/tmpfiles.d/rsaw.conf #Type Path Mode UID GID Age Arg d /rsaw 0770 rsaw rsaw 10s [root]# ping localhost >/rsaw/openfile & [1] 4731 [root]# sleep 10 [root]# systemd-tmpfiles --clean [root]# ll /rsaw total 4 -rw-r--r--. 1 root root 3610 Dec 4 12:53 openfile
In the above, the
/rsaw
dir is meant to be cleaned when files have gone more than 10 seconds without being accessed --/rsaw/openfile
doesn't get deleted bysystemd-tmpfiles --clean
because theping
command is running in the background constantly writing -
Continuing the above example:
[root]# fg ping localhost > /rsaw/openfile ^C [root]# less /rsaw/openfile [1]+ Stopped less /rsaw/openfile [root]# lsof +D /rsaw COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME less 4770 root 4r REG 253,3 7692 2033468 /rsaw/openfile [root]# sleep 10 [root]# systemd-tmpfiles --clean [root]# ll /rsaw total 0
So the
ping
command is killed and thenless
opens the output file -- after waiting 10 seconds,systemd-tmpfiles --clean
deletes the file, despite it still being open byless
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments