tmpfiles footgun, apply directly to the forehead
tmpfiles footgun, apply directly to the forehead
Posted Jun 16, 2024 17:11 UTC (Sun) by bluca (subscriber, #118303)In reply to: tmpfiles footgun, apply directly to the forehead by flussence
Parent article: systemd 256 released
I remain extremely skeptical that it actually happened. This is not a user-facing tool - and I mean the entire sd-tmpfiles, not just the new option. It's ran by units on boot and on timer events, and by packaging scriptlets. I am not aware of any documentation or manpage or hint or blog or anything that suggests "this is the tool you want to run manually to do random stuff".
I cannot possibly figure out the sequence of events that could accidentally and in good faith lead from (A) "I don't know what tmpfiles is or does or how it works or even that it exists. I want to delete some files from /var/cache/" to (B) "I will run sd-tmpfiles --purge as root without any specific configuration or input". I can't really see a path from A to B that is not artificially manufactured, and seeing where it came from, how it started and how it developed (ie, the usual pile on), further enhances my skepticism.
Of course having unclear footguns is not nice, so what we'll likely do is make this switch only act on specific input, and refuse to run 'globally', so you really have to say "please delete this and this", otherwise it does nothing. This seems like a decent compromise to me.
Posted Jun 16, 2024 18:07 UTC (Sun)
by mb (subscriber, #50428)
[Link] (11 responses)
I found this in my default Debian config:
Q /home 0755 - - -
What does that even mean? And no, tmpfiles.d(5) is not at all helpful here.
Q /subvolume-or-directory/to/create mode user group cleanup-age -
What the hell? Cleanup for home? How do I switch it off? I can't find it in the manpage.
Managing /home with anything that has "tmp" in its name is a *serious* design mistake.
Posted Jun 16, 2024 19:02 UTC (Sun)
by MarcB (guest, #101804)
[Link]
Cleanup it is switched off, as indicated by "-".
To completely disable management of /home and /srv, place an empty home.conf in /etc/tempfiles.d/
> Managing /home with anything that has "tmp" in its name is a *serious* design mistake.
It's a configuration mistake. Arguably /home and /srv should not be included in the upstream configuration. It's just a footgun for people who like to run commands they don't understand as root. Since such people exist, deployments that need management of those folder should explicitly enable it.
Posted Jun 16, 2024 21:26 UTC (Sun)
by bluca (subscriber, #118303)
[Link] (9 responses)
None of this has anything to do with "tmpfiles" - it is just an unfortunate legacy name (that cannot be changed without breaking scripts), but sd-tmpfiles has not been about temporary files for years and years. Just check the entries in the tmpfiles.d directory, you'll see plenty of stuff under /etc/ and /var/.
Its purpose today, and since quite some time, is providing declarative configuration for creating/removing/purging files and directories that are not shipped directly inside packages, which translates to pretty much anything outside of the vendor tree (/usr/).
Posted Jun 16, 2024 21:38 UTC (Sun)
by mb (subscriber, #50428)
[Link] (4 responses)
That doesn't make a lot of sense to me.
In fact, I use btrfs and I do _not_ want these to be subvolumes.
Posted Jun 16, 2024 21:40 UTC (Sun)
by bluca (subscriber, #118303)
[Link] (2 responses)
Then mask it/override it. It's a default configuration drop-in, shipped in /usr/ exactly to allow modifying to one's liking, this is 100% supported
Posted Jun 16, 2024 21:48 UTC (Sun)
by mb (subscriber, #50428)
[Link] (1 responses)
Yeah, thanks for letting me know on LWN.
What about: Do not change defaults. Ok?
Posted Jun 16, 2024 22:44 UTC (Sun)
by bluca (subscriber, #118303)
[Link]
It's not important information at all, and no defaults are changed. If you manually run some tools you don't know anything about, then you should read its documentation and the configuration files that come with it beforehand, that's just common sense. Nothing happens if you don't run it, so you don't have anything to worry about. As clearly explained in the documentation, these subvolumes are only created if the directories are missing, which happens only on firstboot with a read-only rootfs subvolume.
Posted Jun 17, 2024 1:54 UTC (Mon)
by Kamilion (guest, #42576)
[Link]
Posted Jun 17, 2024 4:34 UTC (Mon)
by jccleaver (guest, #127418)
[Link] (1 responses)
What? Scope creep in systemd leading to bombs left for sysadmins years after the fact to discover the hard way? Surely not! That's impossible.
This ranks up there with the "Bricking laptops via an errant 'rm' command is a Good Thing" rationalization.
Posted Jun 17, 2024 5:45 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link]
Posted Jun 17, 2024 14:34 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
Can't you rename it with a link to the previous name, and a note in the docu saying "these two are the same, but the old name is misleading and deprecated"?
I'm sure they do that elsewhere ...
Cheers,
Posted Jun 17, 2024 15:20 UTC (Mon)
by bluca (subscriber, #118303)
[Link]
Posted Jun 18, 2024 21:32 UTC (Tue)
by bluca (subscriber, #118303)
[Link]
v256.1 has been released with this change. Much ado about nothing.
Posted Jun 22, 2024 15:26 UTC (Sat)
by flussence (guest, #85566)
[Link] (1 responses)
It's in $PATH. If it's not a user-facing tool it goes in /usr/libexec. Just admit you were wrong. You didn't even fix this, Lennart did.
If you worked in a real engineering profession, your attitude would get people killed.
Posted Jun 22, 2024 20:27 UTC (Sat)
by pizza (subscriber, #46)
[Link]
... So is 'rm', 'dd', 'fdisk', 'mkfs.*' and many other tools (including good old shell output redirection) that can be trivially used to completely trash your files.
> If you worked in a real engineering profession, your attitude would get people killed.
In a "real" profession you can (1) explicitly define who your users/target audience are, and (2) legally require them to undergo formal training before getting on your ride.
tmpfiles footgun, apply directly to the forehead
/home is the most NON-temporary file that exists on a normal system.
The manpage says:
tmpfiles footgun, apply directly to the forehead
You can verify success on older Systemds via "systemd-tmpfiles --cat-config | grep home"
tmpfiles footgun, apply directly to the forehead
The reason there's a config entry for the /home and /srv top level directories is to allow seamlessly making those into subvolumes for the BTRFS use case.
tmpfiles footgun, apply directly to the forehead
If I wanted these directories to be subvolumes, I would have created them as such. No magic "help" from systemd required.
tmpfiles footgun, apply directly to the forehead
tmpfiles footgun, apply directly to the forehead
Much appreaciated, that I have to be on LWN to get that important information about what defaults you changed on my system.
tmpfiles footgun, apply directly to the forehead
Ubuntu's defaults for btrfs root have been subvolumes for @home and @ for over a decade
The apt-btrfs-snapshot package will add a hook that takes a snapshot of @ while excluding @home during most package management activities. I've found it to be quite helpful in the past *decade* since it's introduction somewhere around 2011-2013.
tmpfiles footgun, apply directly to the forehead
tmpfiles footgun, apply directly to the forehead
tmpfiles footgun, apply directly to the forehead
Wol
tmpfiles footgun, apply directly to the forehead
tmpfiles footgun, apply directly to the forehead
tmpfiles footgun, apply directly to the forehead
tmpfiles footgun, apply directly to the forehead