2 ms·
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
by 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 agoFrom 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