On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote:
> 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.)

In any case, there isn't any recommendation either. It even says "If
you want to set kernel variables you can either edit /etc/sysctl.conf
or [...]", so that editing /etc/sysctl.conf seems fine according to
this file.

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

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

This is rather poor design, because
  * there isn't a way to say that some default setting must be
    preserved;
  * changes by a user must be respected by the package, but a package
    may decide that such a file is no longer read!

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

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

The changelog is just wrong... or actually the intended behavior
was to remove the file, but this is buggy:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076352

But just removing the file is against the policy! Still, it must be
removed because systemd's decision to remove the symlink was done
based on the assumption that /etc/sysctl.conf no longer exists.
IMHO, the best solution would be to propose to move it into
"/etc/sysctld.d".

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

On some of my machines (installed quite recently), I hadn't modified
this file, and it wasn't removed.

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

Reply via email to