On Sun, Jul 28, 2024 at 01:04:14 +0200, Vincent Lefevre wrote: > On 2024-07-27 10:23:01 +0200, Michel Verdier wrote: > > /etc/sysctl.d/README.sysctl recommends to use a separate file such as > > /etc/sysctl.d/local.conf > > No, it does *not* recommend anything: > > ------------------------------------------------------------------------ > Files located in this directory can set kernel parameters using the > sysctl(8) or systemd-sysctl(8) tool which is typically run with a > unit/init file started during the boot sequence. > > For details regarding the configuration files refer to > sysctl.d(5) or sysctl.conf(5) > ------------------------------------------------------------------------
You're on unstable. In bookworm, it says this: ------------------------------------------------------------------------ Kernel system variables configuration files Files found under the /etc/sysctl.d directory that end with .conf are parsed within sysctl(8) at boot time. If you want to set kernel variables you can either edit /etc/sysctl.conf or make a new file. The filename isn't important, but don't make it a package name as it may clash with something the package builder needs later. It must end with .conf though. My personal preference would be for local system settings to go into /etc/sysctl.d/local.conf but as long as you follow the rules for the names of the file, anything will work. See sysctl.conf(8) man page for details of the format. After making any changes, please run "service procps force-reload" (or, from a Debian package maintainer script "deb-systemd-invoke restart procps.service"). ------------------------------------------------------------------------ (Wrong section number, too.) Bear in mind that the overwhelming majority of users reading this mailing list are on stable or older. Most of us have no idea what unstable looks like, unless you tell us. > Worse, it refers to the sysctl.conf(5) man page, which lists > /etc/sysctl.conf as the possible files: Agreed -- that should be changed. I think there's a bug report opened for that already...? Yes, it's one of yours: https://bugs.debian.org/1077187 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. > > 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. > > What does a regular file make different compared to a conffile > concerning its handling? A conffile is user-managed, so any changes you make to a conffile must be respected by the package. It can't just overwrite your changes, or restore a conffile if you've deleted it. > > In unstable, apparently, *both* of them are gone. > > No, /etc/sysctl.conf is not gone on existing installations. > It is just no longer read. It's... not? Then what the hell does the procps change text mean? > > while > > <https://metadata.ftp-master.debian.org/changelogs//main/p/procps/procps_4.0.4-5_changelog> > > says: > > procps (2:4.0.4-5) unstable; urgency=medium > > > > * Add Recommends: linux-sysctl-defaults Closes: #1074156 > > * Remove /etc/sysctl.conf as using /etc/sysctl.d/*.conf is better > > * Updated /etc/sysctld.d/README That sure sounds like it's removed, to me. > only for *new* installations. Well... it's a conffile. If you made any changes to it, then the package can't just remove it during an upgrade. I'm not sure what would happen to an unmodified /etc/sysctl.conf file during an upgrade. This isn't a common situation. > There's a bug about it (about existing installations). But the systemd > change should have been done *after* the future correction of procps > in order not to break configuration. Then it's a good thing these changes haven't made their way into a release yet. This is what the unstable -> testing -> release process is for. And thank you for filing bug reports.
