systemd-tmpfiles should skip mountpoints #12692
Comments
|
Can you please show I think it's fine to have a removal option that doesn't introspect past mountpoints, but I don't think systemd-tmpfiles should do that by default. |
cdown
added
needs-discussion 🤔
needs-reporter-feedback ❓
|
Hi, thanks for your reply. Apparently systemd 234 does not have |
|
|
|
Thanks for your patience. There are three |
|
We do check for mount points in the "file aging" code, in fact always have. There are even two checks in that code: https://github.com/systemd/systemd/blob/master/src/tmpfiles/tmpfiles.c#L551 First we check that st_dev of all files we look at is the same as the st_dev of the top-level dir we are operating on. This check should filter out most cases, except those where you bind mount an fs on itself, i.e. where st_dev of a dir and its child match even though the latter is a mount point. This is then followed by a test with dir_is_mount_point(), which uses name_to_handle_at(). That syscall returns us the mnt id of a path, which is different for each actual mount point. sadly, that syscall is not implemented on all file systems, and I figure not on the two your chose for /tmp and yous sshfs. That said, the first check should already have figured out everything and skipped the entry. What is the output of |
|
|
so dev_t in the two dirs is different: 2bh vs 3eh. I have no idea why our check hence didn't work for you. Can you reproduce this? If so, can you step through it (with gdb) and see what the if check I linked above results in in your case on the relevant mount? But before that, please update to a current systemd version, we actually don't track issues here with anything older than the two most recently released systemd versions, i.e. 241 or 242 right now. Even better, please test this with a tmpfiles version that includes #12822, which should improve the second check (even though the first check have already caught your case) |
|
I could reproduce the issue - and the culprit probably isn't systemd. I rebooted my machine, mounted a remote folder with sshfs and created files with different modification timestamps in it: Then, on my workstation, I waited for the first run of I checked the files at irregular intervals, until, after one and a half hours, files older than 14 days were missing. However, Looking into So Gnome probably is the culprit. |
|
Urks. There was (is?) a bug about that asking gsd to just drop their clean-up logic, at least of systemd based systems. It's not just worse than tmpfiles in regards to the mount point detection it's actively detrimental to the system, since their code runs unprivileged, and that means they cannot use O_NOATIME and that in turns means the keep touching the atime of all dirs they look at and thus break the aging logic in tmpfiles. There's really no point in having a second implementation of the clean-up logic in gnome when we already have it better, and their logic even breaks the system logic we need anyway. Gah. |
I quickly mounted a remote location (with
sshfs) into/tmp/foo. Thensystemd-tmpfiles-clean.timerkicked in andsystemd-tmpfiles-clean.serviceexecutedsystemd-tmpfiles, which deleted all files older than 14 days in my mount.Of course
/tmpis not the perfect place for mounts. Butsystemd-tmpfilesshould really skip mountpoints.Fedora 27, systemd 234-11.
The text was updated successfully, but these errors were encountered: