5 ms·

Running "systemd-tmpfiles --purge" will delete /home in systemd 256

60 points by josephcsible 2y ago

exe34 2y ago
[flagged]
deleted 2y ago
[deleted]
dazzawazza 2y ago
Didn't release 256 promise less Unix? Delivered.
deleted 2y ago
[deleted]
theamk 2y ago
better context: https://github.com/systemd/systemd/issues/33349 https://github.com/systemd/systemd/issues/33349 that's already fixed, and by Poettering no less: https://github.com/bluca/systemd/commit/c4220bd2d390e9b330e835256182130d3bd5b94a https://github.com/bluca/systemd/commit/c4220bd2d390e9b330e8...
- jauntywundrkind 2y ago
  From the new docs, > 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 https://0pointer.net/blog/dynamic-users-with-systemd.html
grotorea 2y ago
For the lazy, link to the github discussion: https://github.com/systemd/systemd/issues/33349 https://github.com/systemd/systemd/issues/33349 I was going to make a stupid joke but the first answer did it better: "Home is temporary, David, for we are mere mortals"
- gwern 2y ago
  What an outrageous (and yet, predictable) response by the first systemd developer trying to WONTFIX it (not even to the extent of adding a note in the man page): https://github.com/systemd/systemd/issues/33349#issuecomment-2168794281 https://github.com/systemd/systemd/issues/33349#issuecomment... > 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.
  - deleted 2y ago
    [deleted]
  - phone8675309 2y ago
    When Lennart is telling you to not be a dick then you know you've really fucked up
  - justsomehnguy 2y ago
    Ah, the usual: - obscure command names - data loss by default - blaming the user There is a reason many are not quite happy to embrace this wonderful ecosystem.
- deleted 2y ago
  [deleted]
arp242 2y ago
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 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.
- deleted 2y ago
  [deleted]
- arianvanp 2y ago
  This was brought up 5 years ago already. https://github.com/systemd/systemd/issues/12447 https://github.com/systemd/systemd/issues/12447
  - oliwarner 2y ago
    Woof. Poettering's "[not] really worth the effort if besides some bikeshedding about the name" didn't age well. 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.
- 2y ago
jmclnx 2y ago
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.
- eternityforest 2y ago
  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.
craftkiller 2y ago
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.
- josephcsible 2y ago
  Btrfs and snapper give you basically the same thing, without needing any out-of-tree kernel modules.
  - craftkiller 2y ago
    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."
  - doublepg23 2y ago
    If you're using btrfs on /home you won't need systemd to delete it because it'll already be corrupt. /s
squigz 2y ago
Why do I have to click Show More on almost every post in this thread?
- dpkirchner 2y ago
  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.
erik_seaberg 2y ago
> /home should hence be created on first boot > 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.
Asooka 2y ago
Reason number 256 to never run Linux on any of your personal computers.

60 points by josephcsible 2y ago

exe34 2y ago

[flagged]

deleted 2y ago

[deleted]

dazzawazza 2y ago

Didn't release 256 promise less Unix? Delivered.

deleted 2y ago

[deleted]

theamk 2y ago

better context: https://github.com/systemd/systemd/issues/33349 https://github.com/systemd/systemd/issues/33349 that's already fixed, and by Poettering no less: https://github.com/bluca/systemd/commit/c4220bd2d390e9b330e835256182130d3bd5b94a https://github.com/bluca/systemd/commit/c4220bd2d390e9b330e8...

jauntywundrkind 2y ago
From the new docs, > 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 https://0pointer.net/blog/dynamic-users-with-systemd.html

grotorea 2y ago

For the lazy, link to the github discussion: https://github.com/systemd/systemd/issues/33349 https://github.com/systemd/systemd/issues/33349 I was going to make a stupid joke but the first answer did it better: "Home is temporary, David, for we are mere mortals"

gwern 2y ago
What an outrageous (and yet, predictable) response by the first systemd developer trying to WONTFIX it (not even to the extent of adding a note in the man page): https://github.com/systemd/systemd/issues/33349#issuecomment-2168794281 https://github.com/systemd/systemd/issues/33349#issuecomment... > 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.
- deleted 2y ago
  [deleted]
- phone8675309 2y ago
  When Lennart is telling you to not be a dick then you know you've really fucked up
- justsomehnguy 2y ago
  Ah, the usual: - obscure command names - data loss by default - blaming the user There is a reason many are not quite happy to embrace this wonderful ecosystem.
deleted 2y ago
[deleted]

arp242 2y ago

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 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.

deleted 2y ago
[deleted]
arianvanp 2y ago
This was brought up 5 years ago already. https://github.com/systemd/systemd/issues/12447 https://github.com/systemd/systemd/issues/12447
- oliwarner 2y ago
  Woof. Poettering's "[not] really worth the effort if besides some bikeshedding about the name" didn't age well. 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.
2y ago

jmclnx 2y ago

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.

eternityforest 2y ago
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.

craftkiller 2y ago

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.

josephcsible 2y ago
Btrfs and snapper give you basically the same thing, without needing any out-of-tree kernel modules.
- craftkiller 2y ago
  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."
- doublepg23 2y ago
  If you're using btrfs on /home you won't need systemd to delete it because it'll already be corrupt. /s

squigz 2y ago

Why do I have to click Show More on almost every post in this thread?

dpkirchner 2y ago
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.

erik_seaberg 2y ago

> /home should hence be created on first boot > 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.

Asooka 2y ago

Reason number 256 to never run Linux on any of your personal computers.