systemd may silently break your system!

[Vincent Lefevre]

The /etc/sysctl.d/99-sysctl.conf symlink has been removed
(currently in unstable) *without any announcement*, so that
the /etc/sysctl.conf file (which is still documented, BTW)
is no longer read.

So, be careful if you have important settings there (security...).

[allan]

I had already removed the symlink and migrated sysctl.conf to
99-sysctl.conf and it appears Debian deleted that file as well.

Post by Vincent Lefevre
The /etc/sysctl.d/99-sysctl.conf symlink has been removed
(currently in unstable) *without any announcement*, so that
the /etc/sysctl.conf file (which is still documented, BTW)
is no longer read.
So, be careful if you have important settings there (security...).
--
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Jeffrey Walton]

Post by Vincent Lefevre
The /etc/sysctl.d/99-sysctl.conf symlink has been removed
(currently in unstable) *without any announcement*, so that
the /etc/sysctl.conf file (which is still documented, BTW)
is no longer read.
So, be careful if you have important settings there (security...).

I had to laugh when I saw the title:

systemd may silently break your system!

So what's new in the world according to Poettering?

Jeff

[Michel Verdier]

Post by Vincent Lefevre
The /etc/sysctl.d/99-sysctl.conf symlink has been removed
(currently in unstable) *without any announcement*, so that
the /etc/sysctl.conf file (which is still documented, BTW)
is no longer read.
So, be careful if you have important settings there (security...).

/etc/sysctl.d/README.sysctl recommends to use a separate file such as
/etc/sysctl.d/local.conf

[Greg Wooledge]

Post by Vincent Lefevre
The /etc/sysctl.d/99-sysctl.conf symlink has been removed
(currently in unstable) *without any announcement*, so that
the /etc/sysctl.conf file (which is still documented, BTW)
is no longer read.
So, be careful if you have important settings there (security...).

I kept wondering: what does this have to do with the Subject
header? The files in question belong to the procps package, not
to systemd, right?

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.

In unstable, apparently, *both* of them are gone.

<https://metadata.ftp-master.debian.org/changelogs//main/s/systemd/systemd_256.4-2_changelog> says:
[ Luca Boccassi ]
* Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
/etc/sysctl.conf (Closes: #1076190)

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

So it seems to have been a removal performed at the whim of the procps
maintainer. Perhaps there was discussion somewhere amongst the developers
that I'm not aware of.

It does seem like the sort of change that would belong in the NEWS
file, but I don't see it in
<https://salsa.debian.org/debian/procps/-/blob/master/debian/NEWS?ref_type=heads>.

[David Wright]

Post by Greg Wooledge

Post by Vincent Lefevre
The /etc/sysctl.d/99-sysctl.conf symlink has been removed
(currently in unstable) *without any announcement*, so that
the /etc/sysctl.conf file (which is still documented, BTW)
is no longer read.
So, be careful if you have important settings there (security...).

I kept wondering: what does this have to do with the Subject
header? The files in question belong to the procps package, not
to systemd, right?
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.
In unstable, apparently, *both* of them are gone.
[ Luca Boccassi ]
* Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
/etc/sysctl.conf (Closes: #1076190)
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
So it seems to have been a removal performed at the whim of the procps
maintainer. Perhaps there was discussion somewhere amongst the developers
that I'm not aware of.
It does seem like the sort of change that would belong in the NEWS
file, but I don't see it in
<https://salsa.debian.org/debian/procps/-/blob/master/debian/NEWS?ref_type=heads>.

I'd agree (it's a NEWS bug), but the file is AFAICT functionless.
If you've added any functionality to it, then I'd expect upgrading
procps to give the usual dialogue whenever a conffile has been
modified.

But if you have installed systemd without procps in the past, did
that just result in a dangling symlink? As I have both systemd
and procps installed, I'm not sure what happens in this case.

As far as moving the file is concerned, I would have thought
this was just part of the evolution from big-file-under-/etc/
to individual-snippets-under-/etc/foo.d/ that's been happening
for years. And I can't find another instance on my system of
a /etc/foo.d/NN-bar → /etc/bar.conf where the symlink has a
sequence number. (IOW bar.conf doesn't "know" that it's part of
an ordered collection of configurations.)

Cheers,
David.

[Vincent Lefevre]

Post by Greg Wooledge

Post by Vincent Lefevre
The /etc/sysctl.d/99-sysctl.conf symlink has been removed
(currently in unstable) *without any announcement*, so that
the /etc/sysctl.conf file (which is still documented, BTW)
is no longer read.
So, be careful if you have important settings there (security...).

I kept wondering: what does this have to do with the Subject
header? The files in question belong to the procps package, not
to systemd, right?

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)

Post by Greg Wooledge
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?

Post by Greg Wooledge
In unstable, apparently, *both* of them are gone.

No, /etc/sysctl.conf is not gone on existing installations.
It is just no longer read.

Post by Greg Wooledge
[ Luca Boccassi ]
* Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
/etc/sysctl.conf (Closes: #1076190)

/etc/sysctl.conf is no longer shipped only for *new* installations.
But /etc/sysctl.d/99-sysctl.conf got removed also for *existing*
installations.

Post by Greg Wooledge
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

only for *new* installations.

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.

[Greg Wooledge]

Post by Vincent Lefevre

Post by Michel Verdier
/etc/sysctl.d/README.sysctl recommends to use a separate file such as
/etc/sysctl.d/local.conf

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

Post by Vincent Lefevre
Worse, it refers to the sysctl.conf(5) man page, which lists

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

Post by Vincent Lefevre
* 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.

Post by Vincent Lefevre

Post by Michel Verdier
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.

Post by Vincent Lefevre

Post by Michel Verdier
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?

Post by Vincent Lefevre

Post by Michel Verdier
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.

Post by Vincent Lefevre
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.

Post by Vincent Lefevre
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.

[Vincent Lefevre]

Post by Vincent Lefevre

Post by Vincent Lefevre

Post by Michel Verdier
/etc/sysctl.d/README.sysctl recommends to use a separate file such as
/etc/sysctl.d/local.conf

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

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

Post by Vincent Lefevre

Post by Vincent Lefevre
* 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).

Post by Vincent Lefevre

Post by Vincent Lefevre

Post by Michel Verdier
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).

Post by Vincent Lefevre

Post by Vincent Lefevre

Post by Michel Verdier
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?

Post by Vincent Lefevre

Post by Michel Verdier
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".

Post by Vincent Lefevre

Post by Vincent Lefevre
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.

[David Wright]

Post by Vincent Lefevre

Post by Greg Wooledge

Post by Greg Wooledge
* 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.

Post by Vincent Lefevre

Post by Greg Wooledge

Post by Greg Wooledge

Post by Greg Wooledge
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.

Post by Vincent Lefevre

Post by Greg Wooledge

Post by Greg Wooledge
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;

There is: just add an empty comment line. Now you own that default.

Post by Vincent Lefevre
* 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.

Post by Vincent Lefevre
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?

SYSCTL.D(5) sysctl.d SYSCTL.D(5)

NAME
sysctl.d - Configure kernel parameters at boot

SYNOPSIS
/etc/sysctl.d/*.conf ← sysadmin's configuration overrides
/run/sysctl.d/*.conf ← ephemeral overrides
/usr/local/lib/sysctl.d/*.conf ← local package's overrides
/usr/lib/sysctl.d/*.conf ← Debian/systemd's default configuration

Post by Vincent Lefevre

Post by Greg Wooledge

Post by Greg Wooledge

Post by Greg Wooledge
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?

Post by Greg Wooledge

Post by Greg Wooledge
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
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076352
But just removing the file is against the policy!

But two things:

. This [Policy] manual cannot and does not prohibit every
possible bug or undesirable behaviour.

. The Release Team can, at their discretion, downgrade
a Policy requirement to a Policy recommendation for
a given release of the Debian distribution.

and, of course, unstable is never released.

Post by Vincent Lefevre
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".

Post by Greg Wooledge

Post by Greg Wooledge
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 don't think it would break Policy for a new empty configuration
file to be supplied. You would of course be warned and allowed to
keep your old version in the usual manner, even though it would
become impotent after the upgrade.

Post by Vincent Lefevre

Post by Greg Wooledge
I'm not sure what would happen to an unmodified /etc/sysctl.conf file
during an upgrade. This isn't a common situation.

It gets blown away: "Obsolete configuration files without local
changes should be removed by the package during upgrade."

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

Between bookworm and trixie, the migration issue for a modified
/etc/sysctl.conf file will have had to be sorted out. Perhaps it will
migrate it for you, presumably as 99-… so that it sorts in the same
way as now. AIUI your bug report should assist in that process, but
unstable is for finding these snags when packages are split, merged,
or otherwise refactorised.

Cheers,
David.

[Vincent Lefevre]

Post by David Wright

Post by Vincent Lefevre

Post by Greg Wooledge

Post by Greg Wooledge
* 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

Post by David Wright

Post by Vincent Lefevre

Post by Greg Wooledge

Post by Greg Wooledge

Post by Greg Wooledge
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).

Post by David Wright

Post by Vincent Lefevre
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).

Post by David Wright

Post by Vincent Lefevre
* 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.

Post by David Wright

Post by Vincent Lefevre
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).

[Greg Wooledge]

Post by Vincent Lefevre
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).

I really don't understand what you're asking for here.

There are defaults in /usr/lib/sysctl.d/*.conf (which is documented
in sysctl.d(5) even in bookworm). The files in /etc/sysctl.d/*.conf
will override those defaults.

Configuration files are read from directories in /etc/, /run/,
/usr/local/lib/, and /lib/, in order of precedence, as listed in the
SYNOPSIS section above. Files must have the ".conf" extension. Files in
/etc/ override files with the same name in /run/, /usr/local/lib/, and
/lib/. Files in /run/ override files with the same name under /usr/.

Why do you need to see the literal word "include" in some other file?
What benefit does that give you?

[Vincent Lefevre]

Post by Greg Wooledge

Post by Vincent Lefevre
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).

I really don't understand what you're asking for here.
There are defaults in /usr/lib/sysctl.d/*.conf (which is documented
in sysctl.d(5) even in bookworm). The files in /etc/sysctl.d/*.conf
will override those defaults.
Configuration files are read from directories in /etc/, /run/,
/usr/local/lib/, and /lib/, in order of precedence, as listed in the
SYNOPSIS section above. Files must have the ".conf" extension. Files in
/etc/ override files with the same name in /run/, /usr/local/lib/, and
/lib/. Files in /run/ override files with the same name under /usr/.
Why do you need to see the literal word "include" in some other file?
What benefit does that give you?

Indeed, thanks to the specified ordering (though the recommendations
are not followed by Debian), an include mechanism would probably be
useless here.

But this is an issue for tmpfiles.d, because there is no way to know
whether a file added in /etc/tmpfiles.d will come after some file in
/usr/lib/tmpfiles.d (the issue is for files that could be added in
the future).

[David Wright]

Post by Vincent Lefevre

Post by David Wright

Post by Vincent Lefevre

Post by Greg Wooledge

Post by Greg Wooledge
* 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
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077184

I only wrote that the /order/ was accidental: upgrading systemd before
procps had removed its conffile. When the latter happens, you should
get asked about that conffile, and if not, then that's surely a bug
in procps, not systemd: procps owned the file, so procps disowned it.

In fact, here's procps disowning /etc/sysctl.conf:

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

(the top of /usr/share/doc/procps/changelog.Debian.gz 4.0.4-5)

Post by Vincent Lefevre

Post by David Wright

Post by Vincent Lefevre

Post by Greg Wooledge

Post by Greg Wooledge

Post by Greg Wooledge
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

↑↑↑↑↑↑↑↑ trixie

Post by Vincent Lefevre

Post by David Wright
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).

Sorry, I meant to write trixie, not bookworm; stable and oldstable are
the same. Your complaint is with unstable.

Post by Vincent Lefevre

Post by David Wright

Post by Vincent Lefevre
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).

That doesn't square with Policy, and this typical dialogue that
we've all seen:

Configuration file `foo'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** foo (Y/I/N/O/D/Z) [default=N] ?

Might your merges apply to configuration files rather than conffiles?

Post by Vincent Lefevre

Post by David Wright

Post by Vincent Lefevre
* 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.

I would file a bug against procps rather than systemd, for dropping
the conffile status of /etc/sysctl.conf. Once you upgrade to Debian's
4.0.4-5, that file becomes just any old file that you happen to have
under /etc/, and I don't see why systemd should be obliged to retain
the legacy symlink any longer.

Actually I think you already have.

Post by Vincent Lefevre

Post by David Wright

Post by Vincent Lefevre
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).

Instead of having one big file /etc/sysctl.conf, systemd gives you any
number of small /etc/sysctl.d/*conf files for any and every individual
aspect of sysctl, and in addition you can order them. I don't see the
difference between that (at the filesystem level) and an include
mechanism (at the level of a file).

Cheers,
David.

[Vincent Lefevre]

Post by David Wright

Post by Vincent Lefevre

Post by David Wright
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
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077184

If this were accidental, the bug should have been left open.

Post by David Wright
upgrading systemd before
procps had removed its conffile. When the latter happens, you should
get asked about that conffile, and if not, then that's surely a bug
in procps, not systemd: procps owned the file, so procps disowned it.
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
(the top of /usr/share/doc/procps/changelog.Debian.gz 4.0.4-5)

It was clear in my bug report that this applies only to new
installations.

------------------------------------------------------------------------
The /etc/sysctl.conf file is no longer read, while I have security
settings there.

I suspect that the cause is

* Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
/etc/sysctl.conf (Closes: #1076190)

which is wrong!

cventin:~> dpkg -S /etc/sysctl.conf
procps: /etc/sysctl.conf

with procps 2:4.0.4-5.

Perhaps procps no longer ships /etc/sysctl.conf *by default*, but
existing installations still have it (a machine I installed in
January still has this file).
------------------------------------------------------------------------

Post by David Wright

Post by Vincent Lefevre

Post by David Wright

Post by Greg Wooledge
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

↑↑↑↑↑↑↑↑ trixie

Post by Vincent Lefevre

Post by David Wright
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).

Sorry, I meant to write trixie, not bookworm; stable and oldstable are
the same. Your complaint is with unstable.

But unstable will migrate to trixie. Nothing has been done yet to
remove the man page (and references to /etc/sysctl.conf).

Post by David Wright

Post by Vincent Lefevre
No, this is not sufficient. During an upgrade, a package is allowed
to do a merge of the new defaults (this occurs quite frequently).

That doesn't square with Policy, and this typical dialogue that
Configuration file `foo'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** foo (Y/I/N/O/D/Z) [default=N] ?
Might your merges apply to configuration files rather than conffiles?

There are several ways to update the configuration in an upgrade.
Not every package uses this method.

Post by David Wright
I would file a bug against procps rather than systemd, for dropping
the conffile status of /etc/sysctl.conf. Once you upgrade to Debian's
4.0.4-5, that file becomes just any old file that you happen to have
under /etc/, and I don't see why systemd should be obliged to retain
the legacy symlink any longer.

No, after the upgrade to 4.0.4-5, /etc/sysctl.conf was still seen
as a conffile (and there wasn't any announcement of a change). So
there wasn't any apparent bug in procps.

[David Wright]

Post by Vincent Lefevre

Post by David Wright

Post by Vincent Lefevre

Post by David Wright
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
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077184

If this were accidental, the bug should have been left open.

I agree with the syslogd maintainer: if you want to use what you had
in /etc/sysctl.conf, place it in one or more of the appropriate
directories, like /etc/sysctl.d/. Closing that bug seems fine.

I think the bug is in procps, and I see that your bug is open:

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

However, I'd be complaining about how upgrading procps disposes of
/etc/sysctl.conf, because it was a conffile and is one no longer.
I see that that bug has been reported, that there might be a fix
coming, and that you have contributed to that report (#1076352).

Post by Vincent Lefevre

Post by David Wright
upgrading systemd before
procps had removed its conffile. When the latter happens, you should
get asked about that conffile, and if not, then that's surely a bug
in procps, not systemd: procps owned the file, so procps disowned it.
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
(the top of /usr/share/doc/procps/changelog.Debian.gz 4.0.4-5)

It was clear in my bug report that this applies only to new
installations.
------------------------------------------------------------------------
The /etc/sysctl.conf file is no longer read, while I have security
settings there.
I suspect that the cause is
* Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
/etc/sysctl.conf (Closes: #1076190)
which is wrong!
cventin:~> dpkg -S /etc/sysctl.conf
procps: /etc/sysctl.conf
with procps 2:4.0.4-5.
Perhaps procps no longer ships /etc/sysctl.conf *by default*, but
existing installations still have it (a machine I installed in
January still has this file).
------------------------------------------------------------------------

Yes, you mean new installations of procps. But if procps has not been
upgraded and taken some action wrt your /etc/sysctl.conf, then there's
a risk in upgrading syslogd, which assumes procps has done so as it ought.

That's a risk of running unstable: package upgrades might occur in the
wrong order, and one needs to report bugs like #1076352.

Post by Vincent Lefevre

Post by David Wright

Post by Vincent Lefevre

Post by David Wright

Post by Greg Wooledge
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

↑↑↑↑↑↑↑↑ trixie

Post by Vincent Lefevre

Post by David Wright
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).

Sorry, I meant to write trixie, not bookworm; stable and oldstable are
the same. Your complaint is with unstable.

But unstable will migrate to trixie. Nothing has been done yet to
remove the man page (and references to /etc/sysctl.conf).

I'm guessing it might not be the only documentation lagging behind
the software it describes.

Post by Vincent Lefevre

Post by David Wright

Post by Vincent Lefevre
No, this is not sufficient. During an upgrade, a package is allowed
to do a merge of the new defaults (this occurs quite frequently).

That doesn't square with Policy, and this typical dialogue that
Configuration file `foo'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** foo (Y/I/N/O/D/Z) [default=N] ?
Might your merges apply to configuration files rather than conffiles?

There are several ways to update the configuration in an upgrade.
Not every package uses this method.

This is the only way for conffiles that have been modified. When they
haven't been modified, the upgrade has the freedom to replace them or
whatever. An unmodified /etc/sysctl.conf can be safely removed because
it's functionally empty in bookworm.

I have no idea whether the rules are always followed in unstable.
Again, I'm only writing of conffiles, not configuration files.

Post by Vincent Lefevre

Post by David Wright
I would file a bug against procps rather than systemd, for dropping
the conffile status of /etc/sysctl.conf. Once you upgrade to Debian's
4.0.4-5, that file becomes just any old file that you happen to have
under /etc/, and I don't see why systemd should be obliged to retain
the legacy symlink any longer.

No, after the upgrade to 4.0.4-5, /etc/sysctl.conf was still seen
as a conffile (and there wasn't any announcement of a change).

I don't know where dpkg gets that bug-reported information from.
Obviously I can only see what's in the package itself, not what's on
your system.

$ md5sum procps_4.0.4-5_amd64.deb
bfddcfddca4eb6149f95962fc1196e96 procps_4.0.4-5_amd64.deb
$ dpkg-deb -I procps_4.0.4-5_amd64.deb conffiles
/etc/init.d/procps
/etc/sysctl.d/README.sysctl
$ dpkg-deb -c procps_4.0.4-5_amd64.deb > /tmp/procps_4.0.4-5_amd64.contents
$

(attached)

Post by Vincent Lefevre
So
there wasn't any apparent bug in procps.

Odd, then, that Craig Small is discussing a fix and a 4.0.4-6.
(Unless by apparent you mean "I didn't see the bug coming."
Well, no, that's what bugs do, pop up without notice.)

Cheers,
David.

[Vincent Lefevre]

Post by David Wright

Post by Vincent Lefevre

Post by David Wright

Post by Vincent Lefevre

Post by David Wright
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
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077184

If this were accidental, the bug should have been left open.

I agree with the syslogd maintainer: if you want to use what you had
in /etc/sysctl.conf, place it in one or more of the appropriate
directories, like /etc/sysctl.d/. Closing that bug seems fine.

But this means that by upgrading systemd, the user will suddenly
be affected by the /etc/sysctl.conf issue, without any warning
from apt-listbugs (note that systemd does not have a Breaks on
the buggy procps). This is not satisfactory.

Post by David Wright
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077187

This one is for the documentation only. The bug about the conffile
left behind is

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

Post by David Wright
That's a risk of running unstable: package upgrades might occur in the
wrong order, and one needs to report bugs like #1076352.

No, even for unstable, maintainers should ensure that packages are
upgraded in the right order.

Post by David Wright

Post by Vincent Lefevre

Post by David Wright

Post by Vincent Lefevre
No, this is not sufficient. During an upgrade, a package is allowed
to do a merge of the new defaults (this occurs quite frequently).

That doesn't square with Policy, and this typical dialogue that
Configuration file `foo'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** foo (Y/I/N/O/D/Z) [default=N] ?
Might your merges apply to configuration files rather than conffiles?

There are several ways to update the configuration in an upgrade.
Not every package uses this method.

This is the only way for conffiles that have been modified.

So, the issue is probably for configuration files that are not
conffiles.

There's also the issue with configuration by symbolic links.
How do you tell the system that in future upgrades, you want
to keep some symbolic link (e.g. /etc/sysctl.d/99-sysctl.conf
before upgrading systemd[*])?

[*] Either in unstable, or for the future upgrade from bookworm
to trixie.

[...]

Post by David Wright
(Unless by apparent you mean "I didn't see the bug coming."
Well, no, that's what bugs do, pop up without notice.)

Wrong. apt-listbugs will list major bugs already reported...
but not this one!!!

[Greg Wooledge]

Post by Vincent Lefevre
No, even for unstable, maintainers should ensure that packages are
upgraded in the right order.

Once again, here is my understanding of the current situation:

1) A new procps package was uploaded, which no longer has /etc/sysctl.conf.

2) A new systemd package was uploaded, which removes the now-dangling
/etc/sysctl.d/99-whatever symlink.

3) It was discovered that the new procps package fails to remove the
existing /etc/sysctl.conf file when upgrading. This was filed as
a bug, and will be fixed at some point.

I see NO reason to point fingers of blame at systemd (cf. Subject:).

I see nothing amiss here in the order in which packages were uploaded.

I see NO reason that these two packages have to be upgraded in a specific
order (cf. quoted text). Once the procps bug is fixed, upgrading EITHER
of the two packages will cause the /etc/sysctl.conf to stop being used.
It doesn't MATTER which one is upgraded first.

What exactly is your problem right now? What part of this quite natural
unstable change process has you SO ENRAGED that you keep posting over
and over to this thread? I really can't see it.

Are you angry because your system still has a file that it's not supposed
to have, even though nothing reads that file any longer?

Please get over it. If having an unused file present INFURIATES you,
just remove the stupid file already.

[Vincent Lefevre]

Post by Greg Wooledge

Post by Vincent Lefevre
No, even for unstable, maintainers should ensure that packages are
upgraded in the right order.

1) A new procps package was uploaded, which no longer has /etc/sysctl.conf.
2) A new systemd package was uploaded, which removes the now-dangling
/etc/sysctl.d/99-whatever symlink.
3) It was discovered that the new procps package fails to remove the
existing /etc/sysctl.conf file when upgrading. This was filed as
a bug, and will be fixed at some point.

NO!!! This is (3) before (2).

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076352
"procps: leftover conffiles" on 14 July.

systemd (256.4-1) unstable; urgency=medium
[...]
* Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
/etc/sysctl.conf (Closes: #1076190)
[...]
on 24 July, i.e. 10 days later!

BTW, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076190
"Upgraded systems will continue to have an obsolete conffile named
/etc/sysctl.conf"

so the silent breakage was known and done on purpose.

[Nicolas George]

Post by Vincent Lefevre
so the silent breakage was known and done on purpose.

Cutting yourself on Hanlon's Razor.

[Greg Wooledge]

Post by Vincent Lefevre
so the silent breakage was known and done on purpose.

... OK, you're just living in a personal fantasy. There's nothing more
to be gained by trying to interact with you on this topic, so I'm going
to stop now.

[Andy Smith]

Hi,

Post by Greg Wooledge
I see NO reason to point fingers of blame at systemd (cf. Subject:).
I see nothing amiss here in the order in which packages were uploaded.
I see NO reason that these two packages have to be upgraded in a specific
order (cf. quoted text). Once the procps bug is fixed, upgrading EITHER
of the two packages will cause the /etc/sysctl.conf to stop being used.
It doesn't MATTER which one is upgraded first.

This whole thing just seems like the normal process of developing
and packaging a distribution. Poor interactions are found, reported,
hopefully will be fixed. But once again there's people trying to use
this as a daily driver and having weird expectations. And then some
sort of triggering around anything involving systemd.

I feel like we see it more and more, these expectations about sid,
and I don't understand why.

Thanks,
Andy

[Stephan Seitz]

Post by Andy Smith
I feel like we see it more and more, these expectations about sid,
and I don't understand why.

Maybe because these bugs have already reached testing?

My testing system has this buggy version of procps.
Interestingly /etc/sysctl.conf is still available.

Stephan

[Dan Ritter]

Post by Andy Smith
This whole thing just seems like the normal process of developing
and packaging a distribution. Poor interactions are found, reported,
hopefully will be fixed. But once again there's people trying to use
this as a daily driver and having weird expectations. And then some
sort of triggering around anything involving systemd.
I feel like we see it more and more, these expectations about sid,
and I don't understand why.

There are people who have become invested in the idea that sid
is "stable enough" and have been told that it is comparable to a
rolling release model.

They have been misinformed but seem resistant to correction.

-dsr-

[George at Clug]

Post by Dan Ritter

Post by Andy Smith
This whole thing just seems like the normal process of developing
and packaging a distribution. Poor interactions are found, reported,
hopefully will be fixed. But once again there's people trying to use
this as a daily driver and having weird expectations. And then some
sort of triggering around anything involving systemd.
I feel like we see it more and more, these expectations about sid,
and I don't understand why.

There are people who have become invested in the idea that sid
is "stable enough" and have been told that it is comparable to a
rolling release model.
They have been misinformed but seem resistant to correction.

+1

Thank you for confirming my suspicions.

Due to the number of people running sid as a daily driver, I was starting to doubt my original understanding 'testing!=stable".



George.

Post by Dan Ritter
-dsr-

[Jeffrey Walton]

Post by Dan Ritter

Post by Andy Smith
This whole thing just seems like the normal process of developing
and packaging a distribution. Poor interactions are found, reported,
hopefully will be fixed. But once again there's people trying to use
this as a daily driver and having weird expectations. And then some
sort of triggering around anything involving systemd.
I feel like we see it more and more, these expectations about sid,
and I don't understand why.

There are people who have become invested in the idea that sid
is "stable enough" and have been told that it is comparable to a
rolling release model.
They have been misinformed but seem resistant to correction.

A good reference that explains Stable, Testing, Unstable and
Experimental is in the debian-reference at
<https://www.debian.org/doc/manuals/debian-reference/debian-reference.en.pdf>.

Post by Dan Ritter
From p 42 (of 245), the closest thing to rolling releases appears to

be Testing. The purpose of Testing is described as:

Dynamic testing release after decent checks and short waits

The reference also says:

Only pure stable release with security updates provides the best
stability. Running mostly stable release mixed with some packages from
testing or unstable release is riskier than running pure unstable
release for library version mismatch etc. If you really need the latest
version of some programs under stable release, please use packages from
stable-updates and backports (see Section 2.7.4) services. These
services must be used with extra care.

(I'm just pointing out the reference. It is not for the benefit of
folks like AS and DSR. They already know these things).

Jeff

[Michael Kjörling]

Post by Vincent Lefevre

Post by Greg Wooledge
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).

Isn't that pretty much exactly what /etc/sysctl.d _is_? Packages can
install files listing defaults (possibly commented out) into that
directory, and the administrator can add a file which lexigraphically
comes later which overrides those defaults and which is not touched by
any vendor-provided package.

Same with many other packages as of late which have historically had
relatively monolithic configuration files under /etc. Everything from
bash (/etc/bash_completion.d, /etc/profile.d) to OpenSSH
(/etc/ssh/{ssh,sshd}_config.d) and Apache (/etc/apache2/*-enabled).
This is a _good_ thing IMO, as it reduces brittleness.

It seems to me that if the administrator overrides a default, then the
onus is on the administrator to maintain the intended effect of that
override (including syntactic changes after a package upgrade), or
remove the override if it's no longer relevant or useful.

[allan]

I would agree with you *if* the change had been publicized.

I found the 99-sysctl.conf symlink accidentally. I removed the
symlink and moved sysctl.conf to 99-sysctl.conf since the original
config was not being read. This turned out to be a lousy idea since
the symlink was removed with the next update, which in my case removed
the original file.

Post by Michael Kjörling
It seems to me that if the administrator overrides a default, then the
onus is on the administrator to maintain the intended effect of that
override (including syntactic changes after a package upgrade), or
remove the override if it's no longer relevant or useful.

[Michael Kjörling]

Post by allan
I would agree with you *if* the change had been publicized.

[...] But in my view it is a bug to remove something else than
the symlink even with the same name

At the risk of repeating myself from elsewhere lately on this mailing
list.

This whole thread is about Debian _Unstable_.

Unstable can be EXACTLY what it says on the tin. _Sid breaks toys._
When Unstable breaks, as the saying goes, you get to keep both pieces.
(The value of having regular backups is not restricted to those
running Unstable.)

By all means, file a bug report against the relevant package so that
this can be tracked and fixed. (Actually, _please_ do, if one doesn't
already exist.) I agree that this should be fixed, preferably before
the change makes it into Testing. Posting on debian-user is not how
one files a bug report, however.

And posting on debian-user with a bombastic Subject line which implies
that this is a widespread issue when it really only seems to exist in
Unstable is, quite frankly, in my opinion at best dishonest.

[The Wanderer]

Post by Michael Kjörling

Post by allan
I would agree with you *if* the change had been publicized.

[...] But in my view it is a bug to remove something else than the
symlink even with the same name

At the risk of repeating myself from elsewhere lately on this
mailing list.
This whole thread is about Debian _Unstable_.
Unstable can be EXACTLY what it says on the tin. _Sid breaks toys._
When Unstable breaks, as the saying goes, you get to keep both
pieces. (The value of having regular backups is not restricted to
those running Unstable.)

FWIW: I'm running testing, not unstable, and I already have the procps
change.

I'm not sure I ever had the systemd-suite package which included the
symlink in question, but I do remember having the systemd-suite
changelog entry in question appear - via apt-list-changes - in upgrades
that I've already installed (although I'm not finding it now when I look
in my local changelogs).

Some parts of this, at least, aren't just in sid.

[allan]

I've run Sid exclusively for years; the last time I broke it badly
enough to justify a reinstall was in 2013 and that was for not paying
attention during an upgrade :)

My heartburn is I would have expected to see this change in a
changelog and apt-listchanges didn't say a word about this.

As far as filing a bug report? Since the symlink is now gone I'm not
even sure there's a bug to file :)

And I agree with you on the bombastic subject line.

Post by Michael Kjörling
By all means, file a bug report against the relevant package so that
this can be tracked and fixed. (Actually, _please_ do, if one doesn't
already exist.) I agree that this should be fixed, preferably before
the change makes it into Testing. Posting on debian-user is not how
one files a bug report, however.
And posting on debian-user with a bombastic Subject line which implies
that this is a widespread issue when it really only seems to exist in
Unstable is, quite frankly, in my opinion at best dishonest.

[Vincent Lefevre]

Post by Michael Kjörling
And posting on debian-user with a bombastic Subject line which implies
that this is a widespread issue when it really only seems to exist in
Unstable is, quite frankly, in my opinion at best dishonest.

No, the breakage was done *on purpose* (together with the lack
of announcement).

[Greg Wooledge]

Post by Vincent Lefevre

Post by Michael Kjörling
And posting on debian-user with a bombastic Subject line which implies
that this is a widespread issue when it really only seems to exist in
Unstable is, quite frankly, in my opinion at best dishonest.

No, the breakage was done *on purpose* (together with the lack
of announcement).

All I can tell you is that you should post bug reports on things that
you believe are broken. (Yes, I know you've already made some. If there
are more issues that you feel are not addressed, then maybe you should
post more.)

Ranting on debian-user is extremely unlikely to get anything changed.
You might warn other users that there's an issue, which can be a great
service to the community, but having done that already, continuing to
harp on the same issue repeatedly seems less than productive.

In the interests of posting something *useful*, here's a timeline.
As I understand it, here's what's happened so far:

2024-06-23: bug #1074156 filed against package procps
procps: Depend or Recommend linux-sysctl-defaults
Bug fixed by upload, closed.

2024-07-11: procps (unstable) upload: /etc/sysctl.conf is "removed"
(but not when upgrading)
Closes #1074156

2024-07-12: bug #1076190 filed against package systemd
Installs dangling symlink /etc/sysctl.d/99-sysctl.conf
Bug fixed by upload, closed.

2024-07-24: systemd (unstable) upload: /etc/sysctl.d/99-sysctl.conf
symlink is removed (for upgrades also)
Closes #1076190

2024-07-26: this thread is started on debian-user

2024-07-26: bug #1077184 filed against package systemd
systemd: /etc/sysctl.conf is no longer read
Bug marked as wontfix, closed.

2024-07-26: bug #1077187 filed against package procps
procps: please drop/replace the obsolete sysctl.conf(5) man page
Still open.

[Vincent Lefevre]

Post by Greg Wooledge
In the interests of posting something *useful*, here's a timeline.
2024-06-23: bug #1074156 filed against package procps
procps: Depend or Recommend linux-sysctl-defaults
Bug fixed by upload, closed.
2024-07-11: procps (unstable) upload: /etc/sysctl.conf is "removed"
(but not when upgrading)
Closes #1074156
2024-07-12: bug #1076190 filed against package systemd
Installs dangling symlink /etc/sysctl.d/99-sysctl.conf
Bug fixed by upload, closed.
2024-07-24: systemd (unstable) upload: /etc/sysctl.d/99-sysctl.conf
symlink is removed (for upgrades also)
Closes #1076190
2024-07-26: this thread is started on debian-user
2024-07-26: bug #1077184 filed against package systemd
systemd: /etc/sysctl.conf is no longer read
Bug marked as wontfix, closed.
2024-07-26: bug #1077187 filed against package procps
procps: please drop/replace the obsolete sysctl.conf(5) man page
Still open.

No, this thread was started *after* bug #1077184 (which I reported)
was closed as wontfix and *after* I reported bug #1077187.

[Max Nikulin]

I also have a 99-systcl.conf which is a copy of the former /etc/sysctl.conf

When you are going to replace a file provided by a package, check if it
is a configuration file at first (e.g. dpkg -s). Despite most of files
in /etc/ are marked as configuration files, some are not.

I juste renamed it. But in my view it is a bug to remove something else
than the symlink even with the same name

On the other hand it makes recovery after a fault easier. Dpkg does not
track types of files, have a look into /var/lib/dpkg/info/systemd.list

[David Wright]

Post by Max Nikulin

I also have a 99-systcl.conf which is a copy of the former /etc/sysctl.conf

When you are going to replace a file provided by a package, check if
it is a configuration file at first (e.g. dpkg -s). Despite most of
files in /etc/ are marked as configuration files, some are not.

I think you meant to write conffiles, not configuration files.

Cheers,
David.

[Vincent Lefevre]

Post by Michel Verdier

Post by Vincent Lefevre
The /etc/sysctl.d/99-sysctl.conf symlink has been removed
(currently in unstable) *without any announcement*, so that
the /etc/sysctl.conf file (which is still documented, BTW)
is no longer read.
So, be careful if you have important settings there (security...).

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

Worse, it refers to the sysctl.conf(5) man page, which lists
/etc/sysctl.conf as the possible files:

As the /etc/sysctl.conf file is used to override default kernel
^^^^^^^^^^^^^^^^
parameter values, only a small number of parameters is predefined
in the file. Use /sbin/sysctl -a or follow sysctl(8) to list all
possible parameters. The description of individual parameters can
be found in the kernel documentation.

and in the FILES section:

/etc/sysctl.d/*.conf
/run/sysctl.d/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
/lib/sysctl.d/*.conf
/etc/sysctl.conf
^^^^^^^^^^^^^^^^

So I did exactly as the documentation said, and this got broken!!!

[Geoff]

Post by Vincent Lefevre
The /etc/sysctl.d/99-sysctl.conf symlink has been removed
(currently in unstable) *without any announcement*, so that
the /etc/sysctl.conf file (which is still documented, BTW)
is no longer read.
So, be careful if you have important settings there (security...).

Thanks for the heads-up, my /etc/sysctl.conf was no longer being read. Now moved to a file in /etc/sysctl.d/ tested with:

sysctl --system

now working again.