Re: [systemd-devel] tmpfiles versus tmpwatch
On Wed, Apr 29, 2015 at 10:28:26PM +1200, Roger Qiu wrote: Doesn't relatime still update the time if the file is 1 day old (regardless of modication time), and the current tmpfiles wipes files that are older by 10 days? Yes, everything should work with relatime, unless you set tmpfiles cleanup time to less than 1 day. On modern kernels, with the lazytime option, it will work even if you set it to less than 1 day. commit 0ae45f63d4ef8d8eeec49c7d8b44a1775fff13e8 Author: Theodore Ts'o ty...@mit.edu Date: Mon Feb 2 00:37:00 2015 -0500 vfs: add support for a lazytime mount option Add a new mount option which enables a new lazytime mode. This mode causes atime, mtime, and ctime updates to only be made to the in-memory version of the inode. The on-disk times will only get updated when (a) if the inode needs to be updated for some non-time related change, (b) if userspace calls fsync(), syncfs() or sync(), or (c) just before an undeleted inode is evicted from memory. Since Linux 2.6.30, the kernel defaults to the behavior provided by this option (unless |noatime| was specified), and the |strictatime| option is required to obtain traditional semantics. In addition, since Linux 2.6.30, the file's last access time is always updated if it is more than 1 day old. http://manpages.courier-mta.org/htmlman8/*mount*.8.html On 29/04/2015 10:22 PM, Lennart Poettering wrote: On Wed, 29.04.15 22:08, Roger Qiu (roger@polycademy.com) wrote: Hi Lennart, So there really isn't a fast of way just checking if a file has an open file descriptor on it? Sometimes atime is on relatime, so it only gets updated if modification is earlier. Using relatime is fine, except for /tmp and /var/tmp really. Setting the flag for those file systems is really a poor choice, since it breaks aging things there... I think that relatime is still the default, but lazytime seems to better in all respects. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tmpfiles versus tmpwatch
On Wed, 29.04.15 22:08, Roger Qiu (roger@polycademy.com) wrote: Hi Lennart, So there really isn't a fast of way just checking if a file has an open file descriptor on it? Sometimes atime is on relatime, so it only gets updated if modification is earlier. Using relatime is fine, except for /tmp and /var/tmp really. Setting the flag for those file systems is really a poor choice, since it breaks aging things there... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tmpfiles versus tmpwatch
On Wed, 29.04.15 15:10, Roger Qiu (roger@polycademy.com) wrote: Hello all, I'm planning to use tmpwatch's `fuser` feature. But I'd prefer to run this simple service using systemd's tmpfiles. Does systemd tmpfiles support running `fuser` so that way it won't delete any files that have an open file descriptor? 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. In almost all cases the atime checks we do should be fully sufficient though. Do you have a case where they aren't? (Note that we do compare all unix sockets we find with /proc/net/unix though, which is relatively efficient still. Also, as unix sockets which are actively used do not get their atime bumped this is kinda a necessity to cover them nicely.) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tmpfiles versus tmpwatch
Roger Qiu roger@polycademy.com schrieb:
I'm planning to use tmpwatch's `fuser` feature.
But I'd prefer to run this simple service using systemd's tmpfiles.
Does systemd tmpfiles support running `fuser` so that way it won't
delete any files that have an open file descriptor?
I couldn't see any mention of in the docs and source code
(https://github.com/systemd/systemd/blob/master/src/tmpfiles/tmpfiles.c).
I don't think it will or ever will but I'm not a dev.
The point is: 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.
Such software should put such files in /var/tmp (which is, according to unix
standards, volatile, too, but would survive reboots and files should stay
around 30 days without usage) or in /var/{cache,spool,lib}. For /var/cache
subdirectories you could setup tmpfiles or tmpwatch - whatever is more
appropriate to you.
Files with very long open times and never being touched in a long time just
don't belong into /tmp. And if you want to ensure that a file isn't
accidently deleted too early, don't enable noatime. Use relatime (or maybe
lazytime from the next kernel versions which is much more posix conform).
--
Replies to list only preferred.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tmpfiles versus tmpwatch
Hi Lennart, So there really isn't a fast of way just checking if a file has an open file descriptor on it? Sometimes atime is on relatime, so it only gets updated if modification is earlier. On servers that don't shutdown, processes may access the file for long periods of time, and the atime may not be updated. Thanks, Roger On 29/04/2015 9:33 PM, Lennart Poettering wrote: On Wed, 29.04.15 15:10, Roger Qiu (roger@polycademy.com) wrote: Hello all, I'm planning to use tmpwatch's `fuser` feature. But I'd prefer to run this simple service using systemd's tmpfiles. Does systemd tmpfiles support running `fuser` so that way it won't delete any files that have an open file descriptor? 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. In almost all cases the atime checks we do should be fully sufficient though. Do you have a case where they aren't? (Note that we do compare all unix sockets we find with /proc/net/unix though, which is relatively efficient still. Also, as unix sockets which are actively used do not get their atime bumped this is kinda a necessity to cover them nicely.) Lennart -- Founder of Matrix AI http://matrix.ai/ +61420925975 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
