4 ms·

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, de

by 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.
theamk 2y ago
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. [0] https://github.com/bluca/systemd/commit/c4220bd2d390e9b330e835256182130d3bd5b94a https://github.com/bluca/systemd/commit/c4220bd2d390e9b330e8...
- arp242 2y ago
  The person who implemented this was very clear it was working as intended. Don't try and retcon this as a "bug".
  - theamk 2y ago
    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)
  - deleted 2y ago
    [deleted]
Asooka 2y ago
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".

by arp242 2y ago

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.

theamk 2y ago

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. [0] https://github.com/bluca/systemd/commit/c4220bd2d390e9b330e835256182130d3bd5b94a https://github.com/bluca/systemd/commit/c4220bd2d390e9b330e8...

arp242 2y ago
The person who implemented this was very clear it was working as intended. Don't try and retcon this as a "bug".
- theamk 2y ago
  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)
- deleted 2y ago
  [deleted]

Asooka 2y ago

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