Re: [systemd-devel] sanity check: why am I unable to manage my own directory with systemd-tmpfiles?
On Fri, Jan 31, 2025 at 5:58 PM Brian Reichert wrote: > On Fri, Jan 31, 2025 at 09:32:58AM +0200, Mantas Mikul??nas wrote: > > If you want to only consider modification time, specify it as something > > like "mM:10d" ??? see "Age" in tmpfiles.d(5). > > Actually, this is failing for me: > > 10-153-68-12:~ # cat /usr/lib/tmpfiles.d/foobar.conf > q /home/foobar/tmp 1700 foobar foobar mM:10d > 10-153-68-12:~ # SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --remove > --clean /usr/lib/tmpfiles.d/foobar.conf > Reading config file "/usr/lib/tmpfiles.d/foobar.conf". > [/usr/lib/tmpfiles.d/foobar.conf:1] Invalid age 'mM:10d'. > > That looks like correct syntax, based on that online doc I found. > > If that is correct syntax, does that mean this feature is not > supported by my version of systemd? The feature seems to have been added in v249 according to NEWS in the Git repo. -- Mantas Mikulėnas
Re: [systemd-devel] sanity check: why am I unable to manage my own directory with systemd-tmpfiles?
On Fri, Jan 31, 2025 at 09:32:58AM +0200, Mantas Mikul??nas wrote: > If you want to only consider modification time, specify it as something > like "mM:10d" ??? see "Age" in tmpfiles.d(5). Actually, this is failing for me: 10-153-68-12:~ # cat /usr/lib/tmpfiles.d/foobar.conf q /home/foobar/tmp 1700 foobar foobar mM:10d 10-153-68-12:~ # SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --remove --clean /usr/lib/tmpfiles.d/foobar.conf Reading config file "/usr/lib/tmpfiles.d/foobar.conf". [/usr/lib/tmpfiles.d/foobar.conf:1] Invalid age 'mM:10d'. That looks like correct syntax, based on that online doc I found. If that is correct syntax, does that mean this feature is not supported by my version of systemd? -- Brian Reichert BSD admin/developer at large
Re: [systemd-devel] sanity check: why am I unable to manage my own directory with systemd-tmpfiles?
On Fri, Jan 31, 2025 at 09:32:58AM +0200, Mantas Mikul??nas wrote: > Run it directly on your config file as: > > SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --remove --clean > /path/to/tmpfiles.d/foobar.conf Your debug suggestion was very helpful: Jan 31 10:20:47 10-153-68-12 systemd-tmpfiles[19650]: Reading config file "/usr/lib/tmpfiles.d/foobar.conf". Jan 31 10:20:47 10-153-68-12 systemd-journald[581]: Forwarding to syslog missed 1 messages. Jan 31 10:20:47 10-153-68-12 systemd-tmpfiles[19650]: Running remove action for entry q /home/foobar/tmp Jan 31 10:20:47 10-153-68-12 systemd-tmpfiles[19650]: Running clean action for entry q /home/foobar/tmp Jan 31 10:20:47 10-153-68-12 systemd-tmpfiles[19650]: Cleanup threshold for directory "/home/foobar/tmp" is Tue 2025-01-21 10:20:47.550246 EST Jan 31 10:20:47 10-153-68-12 systemd-tmpfiles[19650]: File "/home/foobar/tmp/example.2024-12-17": change time Thu 2025-01-30 18:02:55.725580 EST is too new. ... Here, systemd-tmpfiles shows it's gating on ctime, not mtime. Well, that's not accurate. If I look at this on-line doc for tmpfiles.d: https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html It does weigh in on this aging: The age of a file system entry is determined from its last modification timestamp (mtime), its last access timestamp (atime), and (except for directories) its last status change timestamp (ctime). By default, any of these three (or two) values will prevent cleanup if it is more recent than the current time minus the age field. But the manpage for tmpfiles.d(5) on my distro (SLES12SP6): 10-153-68-12:~ # rpm -qf /usr/share/man/man5/tmpfiles.d.5.gz systemd-228-157.63.1.x86_64 contains none of that verbiage whatsoever. > If you want to only consider modification time, specify it as something > like "mM:10d" ??? see "Age" in tmpfiles.d(5). I cannot find any reference to this modifier, in either that online doc I cited above, nor in the manpage for tmpfiles.d(5) for my distro. Can you provide a pointer to some doc explaining that directive? > -- > Mantas Mikul??nas -- Brian Reichert BSD admin/developer at large
Re: [systemd-devel] sanity check: why am I unable to manage my own directory with systemd-tmpfiles?
On Fri, Jan 31, 2025 at 10:45:50AM -0500, Brian Reichert wrote: > > If you want to only consider modification time, specify it as something > > like "mM:10d" ??? see "Age" in tmpfiles.d(5). > > I cannot find any reference to this modifier, in either that online > doc I cited above, nor in the manpage for tmpfiles.d(5) for my > distro. > > Can you provide a pointer to some doc explaining that directive? NM, they do seem to be covered in https://www.freedesktop.org/software/systemd/man/tmpfiles.d , just not as clearly laid out as I hoped for. I do appreciate the advice! -- Brian Reichert BSD admin/developer at large
Re: [systemd-devel] sanity check: why am I unable to manage my own directory with systemd-tmpfiles?
Run it directly on your config file as: SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --remove --clean /path/to/tmpfiles.d/foobar.conf (I'd rather place custom configs in /etc/tmpfiles.d and leave /usr for the package management.) Most likely the issue is that systemd-tmpfiles also considers not just the mtime but also access time (it wouldn't do any good if it started removing actively-used files just because they haven't been modified), as well as btime (birth) and ctime (inode change) – the latter two you cannot backdate with `touch`. If you want to only consider modification time, specify it as something like "mM:10d" – see "Age" in tmpfiles.d(5). -- Mantas Mikulėnas
Re: [systemd-devel] sanity check: why am I unable to manage my own directory with systemd-tmpfiles?
On Fri, Jan 31, 2025, at 00:09, Brian Reichert wrote: > I'm trying to manage a new tempdir with systemd-tmpfiles, but I > can't find a set of directives that do what I expect. > > I'm obviously missing something, as there's plenty of documentation > out there, but I can't achieve the desired effect. > > My environment is SLES12SP6, running systemd 228. While this isn't directly help for your situation... systemd 228 is positively ancient (something like 9 years or more). Any documentation you are referring to, other than the documentation on the system itself, is almost certainly written for newer versions and assumes behavior present in those newer versions.
