Running "systemd-tmpfiles --purge" will delete /home in systemd 256
mathstodon.xyz
mathstodon.xyz
> 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.
I just hope this serves a good lesson. Meaningful names are seen more than manages. If your project creeps, be ready to update its name.
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.
[0] https://github.com/bluca/systemd/commit/c4220bd2d390e9b330e8...
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)
... 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
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".
I was going to make a stupid joke but the first answer did it better: "Home is temporary, David, for we are mere mortals"
> 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
Even Poettering isn't down with that.
- obscure command names
- data loss by default
- blaming the user
There is a reason many are not quite happy to embrace this wonderful ecosystem.
> 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.
that's already fixed, and by Poettering no less: https://github.com/bluca/systemd/commit/c4220bd2d390e9b330e8...
> 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
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.
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.