what a silly change to make, and what a silly response. I still had 255 on my Arch machine, and systemd-tmpfiles(1) starts with:
> systemd-tmpfiles creates, deletes, and cleans up volatile and temporary files and directories, using the configuration file format and location specified in tmpfiles.d(5). It must be invoked with one or more options --create, --remove, and --clean, to select the respective subset of operations.
Okay, sounds reasonable. Then I updated to 256, and the intro becomes:
> systemd-tmpfiles creates, deletes, and cleans up files and directories, using the configuration file format and location specified in tmpfiles.d(5). Historically, it was designed to manage volatile and temporary files, as the name suggests, but it provides generic file management functionality and can be used to manage any kind of files. It must be invoked with one or more commands --create, --remove, and --clean, to select the respective subset of operations.
So what, we need to carefully study every systemd changelog to see if "temporary file" has somehow radically changed meaning according to systemd? And that commands that were previously perfectly fine are now hugely destructive? Actually, I can't even easily distil that information from the changelog: https://github.com/systemd/systemd/releases/tag/v256
And look, maybe this is a perfectly reasonable thing to change in some way. But the way this was done, and then the initial response... That guy's brain seems to be suffering from an int overflow or something.
The "purge" option was intended to delete the specific package's state, and it was supposed to be destructive. Compare with "apt remove --purge httpd" which removes all your nice hand crafted server configs.
The bug happened because if there is no config specified, it applies to all configs.. which is obviously not a good idea with purge.
The fix [0] makes purge safe-ish again by requiring a config file, so it won't purge your homedir unless you explicitly tell it to.
you mean the 2nd comment in thread, where bluca said "don't just run random commands"?
Well, it was pretty harsh, but he had a point.. I mean, if someone did "apt remove --purge cron" and then come complaining about /etc/crontab disappearing, what would you tell them?
That said, apparently the "--purge without argument" was _not_ intended, because they removed it entirely, and they were sure it would not break things.
(Compare to "--preserve-root" option to "rm" - that was actually intended behavior, so maintainers there had to specifically add "--no-preserve-root" option)
It should have been split into something like systemd-tmpfiles and systemd-systemfiles. You can keep the same syntax and daemon binary, just keep the configuration of actually temporary and volatile files that can go away at any time separate from the configuration of system files. Running systemd-tmpfiles --cat-config on Arch with SystemD 255 shows some other fun things, like:
... snip ...
# /usr/lib/tmpfiles.d/arch.conf
# copy from factory when missing
C /etc/crypttab
C /etc/fstab
C /etc/group
C /etc/gshadow
C /etc/host.conf
C /etc/hosts
C /etc/issue
C /etc/ld.so.conf
C /etc/nsswitch.conf
C /etc/passwd
C /etc/profile
C /etc/securetty
C /etc/shadow
C /etc/shells
C /etc/subuid
C /etc/subgid
... snip ...
# /usr/lib/tmpfiles.d/home.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# See tmpfiles.d(5) for details
Q /home 0755 - - -
q /srv 0755 - - -
... snip ...
# /usr/lib/tmpfiles.d/openssh.conf
C /etc/pam.d/sshd
C /etc/ssh/moduli
C /etc/ssh/ssh_config
C /etc/ssh/sshd_config
C /etc/ssh/sshd_config.d/99-archlinux.conf
So if I ran --purge on this system I could kiss goodbye to all of /etc/fstab,groups,shadow,passwd; all of /home and /srv; and my entire sshd config. In fact, looking at the list of things managed by systemd-tmpfiles, at most 10% are actual temporary files and the rest are very important system files. In a way it is impressive how much feature creep has set in.
The stated purpose for --purge: to clean up a package's files, also doesn't seem sensible. That's the job of the package manager. If there are some files in the package's folders that weren't part of the original install, then they're obviously modified by the user and should not be touched by default. That's why package managers usually have an option for "remove package" and a separate option or flag for "and literally every file in every directory that belonged to it, including configuration I have modified".
> So an option that is literally documented as saying "all files and directories created by a tmpfiles.d/ entry will be deleted", that you knew nothing about, sounded like a "good idea"? Did you even go and look what tmpfiles.d entries you had beforehand?
>
> Maybe don't just run random commands that you know nothing about, while ignoring what the documentation tells you? Just a thought eh
> tied to the "system is being factory reset" special state
These should have been handled by the distro's installer. They're warning signs of scope creep; their init is trying to do so much that qualified sysadmins can't fully understand it all.
> The primary usecase for this option is to automatically remove files and directories that originally have been created on behalf of an installed packaged at package removal time.
> Warning! This is is usually not the command you want! In most cases --remove is what you are looking for
These seem like good responses, reasonable safeguards & documentation additions.
It also no longer runs without a specific config saying what tmpfiles to manage.
This is scary & annoying, but it just seems like so much manufactured outrage & FUD from people. I agree that it's a bad look for systemd to close discussions so soon, but they also were on it & resolving it quite satisfactorily with due haste. (Well, I guess bluca's initial response was a strong rebuff, but that did get re-steered.)
It would be lovely to get a better picture of how all the pieces slotted together to make this issue possible. It seems like maybe one system is trying to setup subvolumeable quotas for /home in some cases and that somehow triggered this? I feel like the excellent Dynamic Users feature would likely somehow be involved here, but unclear. https://0pointer.net/blog/dynamic-users-with-systemd.html
I wonder if this has to do with that systemd "movable" home thing I read about a while ago ?
Yes, bugs happen, but how could testing miss this. I would think some automated test would have noticed this. After reading the links theamk supplied, somehow a config issue occurred (?) and the change is just to the man page.
A bit confused by the fix. But seems a purge of /home is still possible even after the fix, to me that is very odd. Fun times in the cloud I guess :)
Glad my distro (Slackware) does extensive testing before a each release. But maybe that is easier for that distro since it does not use systemd.
And not being a professional admin, I will not have to worry about this at work.
My first thought was that this functionality is so obscure that maybe it didn't have many eyeballs on it.
I didn't even know the command existed till now, removing temp files from the terminal is not a thing I've ever thought of doing.
Or the automated tests could have been atomic and isolated, maybe the check was just "Temp files are gone, all good, stop the VM and move on in a fresh environment".
I'm more afraid of rm and dd typos than future systemd bug/features in less common commands, just because I actually use those very occasionally when Etcher and the GUI won't do.
Mastodon has a content/trigger warning feature that many folks (ab)use as though it is a tag feature. Official mastodon interfaces treat these all of these warnings the same, hiding the content by default. You can disable the feature while signed in but then you'll also see things that are more traditionally warned of, like discussions of rape or porn. It was a baffling choice.
Once again I am relieved that I run ZFS with zrepl taking a snapshot every 15 minutes. I could `rm -rf /` and be back up and running in 5 minutes with no data loss.
Perhaps, but btrfs has lost all my data twice. There's an old saying in Tennessee that says "Corrupt all my data once, shame on you. Corrupt all my data twice, you can't corrupt all my data again."
> systemd-tmpfiles creates, deletes, and cleans up volatile and temporary files and directories, using the configuration file format and location specified in tmpfiles.d(5). It must be invoked with one or more options --create, --remove, and --clean, to select the respective subset of operations.
Okay, sounds reasonable. Then I updated to 256, and the intro becomes:
> systemd-tmpfiles creates, deletes, and cleans up files and directories, using the configuration file format and location specified in tmpfiles.d(5). Historically, it was designed to manage volatile and temporary files, as the name suggests, but it provides generic file management functionality and can be used to manage any kind of files. It must be invoked with one or more commands --create, --remove, and --clean, to select the respective subset of operations.
So what, we need to carefully study every systemd changelog to see if "temporary file" has somehow radically changed meaning according to systemd? And that commands that were previously perfectly fine are now hugely destructive? Actually, I can't even easily distil that information from the changelog: https://github.com/systemd/systemd/releases/tag/v256
And look, maybe this is a perfectly reasonable thing to change in some way. But the way this was done, and then the initial response... That guy's brain seems to be suffering from an int overflow or something.