On 2024-07-28 00:07:56 -0500, David Wright wrote: > On Sun 28 Jul 2024 at 04:25:32 (+0200), Vincent Lefevre wrote: > > On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote: > > > > On Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent Lefevre wrote: > > > > The configuration got broken by a *systemd* upgrade: > > > > > > > > * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships > > > > /etc/sysctl.conf (Closes: #1076190) > > > > > > The systemd change was only done because of the procps change. After > > > the procps maintainer REMOVED the /etc/sysctl.conf file, the symlink > > > provided by the systemd package was dangling/broken. So the systemd > > > maintainer removed the symlink. > > > > No, the /etc/sysctl.conf file has not been removed (yet) for > > existing installations. > > > > If the goal were to fix the dangling symlink for new installations, > > then the solution should have been to no longer generate the > > /etc/sysctl.d/99-sysctl.conf symlink for new installations (and > > for existing installations, possibly remove it *only* if it was > > dangling). > > It looks accidental to me that systemd did that tidying up before > procps had attempted to remove the file that it (procps) owned.
No, the breakage was done on purpose: my bug report specifically about this breakage by systemd was closed in a rather abrupt way: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077184 > > > > > As it turns out, it's a combination of the two packages. In bookworm, > > > > > /etc/sysctl.conf is a Conffile of the procps package, and > > > > > /etc/sysctl.d/99-sysctl.conf is a regular file (non-Conffile) of > > > > > the systemd package. > > That symlink was suggested as legacy support for reading the conf file > over a decade ago. Bullseye's man 8 sysctl indicates it still reads > /etc/sysctl.conf with its --system option, but bookworm lacks that > manpage, and instead its man 5 sysctl.d lists only files residing > in …/sysctl.d/ directories as being read; hence the legacy symlink. No, I have a bookworm machine, and the sysctl.conf(5) man page is still there (in addition to the sysctl.d(5) man page). > > This is rather poor design, because > > * there isn't a way to say that some default setting must be > > preserved; > > There is: just add an empty comment line. Now you own that default. No, this is not sufficient. During an upgrade, a package is allowed to do a merge of the new defaults (this occurs quite frequently). > > * changes by a user must be respected by the package, but a package > > may decide that such a file is no longer read! > > As I said, I think that happened by accident rather than design, > a consequence of refactorising two packages with two maintainers. See my bug report above. > > A better design could be to provide Debian / vendor defaults (which > > may change) by some kind of include mechanism. This is more or less > > what fail2ban does, with .conf files and .local files (the .conf > > files are not meant to be changed by the user, so that /usr/lib > > might be a better place than /etc). > > Um, isn't that what systemd provides as a matter of routine? More or less. In the systemd case, for each file, either one chooses it, i.e. one has all the current defaults, or one chooses to provide a replacement under /etc, i.e. one entirely replaces the defaults by one's own settings. An include mechanism would allow a finer control of the settings. The sysctl.d configuration system does not allow one to include a file (to get the current defaults and possibly change some of them just after). -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
