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

--
Vincent Lef�vre <[email protected]> - 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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-26, Vincent Lefevre wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-26, Vincent Lefevre wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat 27 Jul 2024 at 09:26:49 (-0400), Greg Wooledge wrote:

On 2024-07-26, Vincent Lefevre wrote:

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-27 10:23:01 +0200, Michel Verdier wrote:

On 2024-07-26, Vincent Lefevre wrote:

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

--
Vincent Lef�vre <[email protected]> - 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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-27 09:26:49 -0400, Greg Wooledge wrote:

On 2024-07-26, Vincent Lefevre wrote:

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)

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?

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

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

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

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

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

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.

--
Vincent Lef�vre <[email protected]> - 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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <[email protected]> - 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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Vincent Lefevre wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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.

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.

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

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

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!

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.

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

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28 Jul 2024 04:25 +0200, from [email protected] (Vincent Lefevre):

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.

--
Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <[email protected]> - 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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jul 28, 2024 at 16:43:01 +0200, Vincent Lefevre wrote:

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-28 11:21:01 -0400, Greg Wooledge wrote:

On Sun, Jul 28, 2024 at 16:43:01 +0200, Vincent Lefevre wrote:

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

--
Vincent Lef�vre <[email protected]> - 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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun 28 Jul 2024 at 16:43:01 (+0200), Vincent Lefevre wrote:

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

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)

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

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.

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?

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon 29 Jul 2024 at 09:23:16 (+0700), Max Nikulin wrote:

On 28/07/2024 20:08, Erwan David wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-28 22:26:10 -0500, David Wright wrote:

On Sun 28 Jul 2024 at 16:43:01 (+0200), Vincent Lefevre wrote:

On 2024-07-28 00:07:56 -0500, David Wright wrote:

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

I only wrote that the /order/ was accidental:

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

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)

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

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

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

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?

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

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.

--
Vincent Lefèvre <[email protected]> - 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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon 29 Jul 2024 at 11:24:25 (+0200), Vincent Lefevre wrote:

On 2024-07-28 22:26:10 -0500, David Wright wrote:

On Sun 28 Jul 2024 at 16:43:01 (+0200), Vincent Lefevre wrote:

On 2024-07-28 00:07:56 -0500, David Wright wrote:

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

I only wrote that the /order/ was accidental:

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

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)

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.

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

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.

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?

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.

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)

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.

drwxr-xr-x root/root 0 2024-07-11 03:41 ./
drwxr-xr-x root/root 0 2024-07-11 03:41 ./etc/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./etc/init.d/
-rwxr-xr-x root/root 959 2024-07-11 03:41 ./etc/init.d/procps
drwxr-xr-x root/root 0 2024-07-11 03:41 ./etc/sysctl.d/
-rw-r--r-- root/root 269 2024-07-11 03:41 ./etc/sysctl.d/README.sysctl drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/bin/
-rwxr-xr-x root/root 26936 2024-07-11 03:41 ./usr/bin/free
-rwxr-xr-x root/root 22840 2024-07-11 03:41 ./usr/bin/kill
-rwxr-xr-x root/root 39344 2024-07-11 03:41 ./usr/bin/pgrep
-rwxr-xr-x root/root 39344 2024-07-11 03:41 ./usr/bin/pidwait
-rwxr-xr-x root/root 35160 2024-07-11 03:41 ./usr/bin/pmap
-rwxr-xr-x root/root 154552 2024-07-11 03:41 ./usr/bin/ps
-rwxr-xr-x root/root 14648 2024-07-11 03:41 ./usr/bin/pwdx
-rwxr-xr-x root/root 31056 2024-07-11 03:41 ./usr/bin/skill
-rwxr-xr-x root/root 22904 2024-07-11 03:41 ./usr/bin/slabtop
-rwxr-xr-x root/root 18760 2024-07-11 03:41 ./usr/bin/tload
-rwxr-xr-x root/root 134768 2024-07-11 03:41 ./usr/bin/top
-rwxr-xr-x root/root 14648 2024-07-11 03:41 ./usr/bin/uptime
-rwxr-xr-x root/root 39648 2024-07-11 03:41 ./usr/bin/vmstat
-rwxr-xr-x root/root 26936 2024-07-11 03:41 ./usr/bin/w
-rwxr-xr-x root/root 31512 2024-07-11 03:41 ./usr/bin/watch
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/sbin/
-rwxr-xr-x root/root 31040 2024-07-11 03:41 ./usr/sbin/sysctl
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/bug/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/bug/procps/ -rw-r--r-- root/root 166 2024-07-11 03:41 ./usr/share/bug/procps/presubj drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/doc/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/doc/procps/ -rw-r--r-- root/root 2199 2024-07-11 03:41 ./usr/share/doc/procps/FAQ.gz -rw-r--r-- root/root 233 2024-07-11 03:41 ./usr/share/doc/procps/NEWS.Debian.gz
-rw-r--r-- root/root 1059 2024-07-11 03:41 ./usr/share/doc/procps/README.Debian
-rw-r--r-- root/root 3426 2024-07-11 03:41 ./usr/share/doc/procps/bugs.md -rw-r--r-- root/root 2948 2024-07-11 03:41 ./usr/share/doc/procps/changelog.Debian.gz
-rw-r--r-- root/root 14253 2023-08-31 04:54 ./usr/share/doc/procps/changelog.gz
-rw-r--r-- root/root 3974 2024-07-11 03:41 ./usr/share/doc/procps/copyright
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/lintian/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/lintian/overrides/ -rw-r--r-- root/root 80 2024-07-11 03:41 ./usr/share/lintian/overrides/procps
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/de/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/de/LC_MESSAGES/
-rw-r--r-- root/root 78634 2024-07-11 03:41 ./usr/share/locale/de/LC_MESSAGES/procps-ng.mo
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/es/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/es/LC_MESSAGES/
-rw-r--r-- root/root 98460 2024-07-11 03:41 ./usr/share/locale/es/LC_MESSAGES/procps-ng.mo
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/fr/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/fr/LC_MESSAGES/
-rw-r--r-- root/root 101461 2024-07-11 03:41 ./usr/share/locale/fr/LC_MESSAGES/procps-ng.mo
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/ka/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/ka/LC_MESSAGES/
-rw-r--r-- root/root 51544 2024-07-11 03:41 ./usr/share/locale/ka/LC_MESSAGES/procps-ng.mo
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/ko/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/ko/LC_MESSAGES/
-rw-r--r-- root/root 102426 2024-07-11 03:41 ./usr/share/locale/ko/LC_MESSAGES/procps-ng.mo
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/pl/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/pl/LC_MESSAGES/
-rw-r--r-- root/root 99983 2024-07-11 03:41 ./usr/share/locale/pl/LC_MESSAGES/procps-ng.mo
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/pt_BR/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/pt_BR/LC_MESSAGES/
-rw-r--r-- root/root 78613 2024-07-11 03:41 ./usr/share/locale/pt_BR/LC_MESSAGES/procps-ng.mo
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/ro/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/ro/LC_MESSAGES/
-rw-r--r-- root/root 105584 2024-07-11 03:41 ./usr/share/locale/ro/LC_MESSAGES/procps-ng.mo
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/sv/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/sv/LC_MESSAGES/
-rw-r--r-- root/root 97284 2024-07-11 03:41 ./usr/share/locale/sv/LC_MESSAGES/procps-ng.mo
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/uk/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/uk/LC_MESSAGES/
-rw-r--r-- root/root 128374 2024-07-11 03:41 ./usr/share/locale/uk/LC_MESSAGES/procps-ng.mo
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/vi/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/vi/LC_MESSAGES/
-rw-r--r-- root/root 73989 2024-07-11 03:41 ./usr/share/locale/vi/LC_MESSAGES/procps-ng.mo
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/zh_CN/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/locale/zh_CN/LC_MESSAGES/
-rw-r--r-- root/root 12985 2024-07-11 03:41 ./usr/share/locale/zh_CN/LC_MESSAGES/procps-ng.mo
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/de/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/de/man1/ -rw-r--r-- root/root 2386 2024-07-11 03:41 ./usr/share/man/de/man1/free.1.gz
-rw-r--r-- root/root 1801 2024-07-11 03:41 ./usr/share/man/de/man1/kill.1.gz
-rw-r--r-- root/root 3941 2024-07-11 03:41 ./usr/share/man/de/man1/pgrep.1.gz
-rw-r--r-- root/root 1523 2024-07-11 03:41 ./usr/share/man/de/man1/pidof.1.gz
-rw-r--r-- root/root 1429 2024-07-11 03:41 ./usr/share/man/de/man1/pmap.1.gz
-rw-r--r-- root/root 17890 2024-07-11 03:41 ./usr/share/man/de/man1/ps.1.gz -rw-r--r-- root/root 765 2024-07-11 03:41 ./usr/share/man/de/man1/pwdx.1.gz
-rw-r--r-- root/root 1954 2024-07-11 03:41 ./usr/share/man/de/man1/skill.1.gz
-rw-r--r-- root/root 2108 2024-07-11 03:41 ./usr/share/man/de/man1/slabtop.1.gz
-rw-r--r-- root/root 1175 2024-07-11 03:41 ./usr/share/man/de/man1/tload.1.gz
-rw-r--r-- root/root 1394 2024-07-11 03:41 ./usr/share/man/de/man1/uptime.1.gz
-rw-r--r-- root/root 1869 2024-07-11 03:41 ./usr/share/man/de/man1/w.1.gz -rw-r--r-- root/root 3274 2024-07-11 03:41 ./usr/share/man/de/man1/watch.1.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/de/man5/ -rw-r--r-- root/root 1381 2024-07-11 03:41 ./usr/share/man/de/man5/sysctl.conf.5.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/de/man8/ -rw-r--r-- root/root 2609 2024-07-11 03:41 ./usr/share/man/de/man8/sysctl.8.gz
-rw-r--r-- root/root 3013 2024-07-11 03:41 ./usr/share/man/de/man8/vmstat.8.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/fr/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/fr/man1/ -rw-r--r-- root/root 2314 2024-07-11 03:41 ./usr/share/man/fr/man1/free.1.gz
-rw-r--r-- root/root 1718 2024-07-11 03:41 ./usr/share/man/fr/man1/kill.1.gz
-rw-r--r-- root/root 1361 2024-07-11 03:41 ./usr/share/man/fr/man1/pmap.1.gz
-rw-r--r-- root/root 17375 2024-07-11 03:41 ./usr/share/man/fr/man1/ps.1.gz -rw-r--r-- root/root 701 2024-07-11 03:41 ./usr/share/man/fr/man1/pwdx.1.gz
-rw-r--r-- root/root 1873 2024-07-11 03:41 ./usr/share/man/fr/man1/skill.1.gz
-rw-r--r-- root/root 2028 2024-07-11 03:41 ./usr/share/man/fr/man1/slabtop.1.gz
-rw-r--r-- root/root 1089 2024-07-11 03:41 ./usr/share/man/fr/man1/tload.1.gz
-rw-r--r-- root/root 1276 2024-07-11 03:41 ./usr/share/man/fr/man1/uptime.1.gz
-rw-r--r-- root/root 1876 2024-07-11 03:41 ./usr/share/man/fr/man1/w.1.gz -rw-r--r-- root/root 3043 2024-07-11 03:41 ./usr/share/man/fr/man1/watch.1.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/fr/man5/ -rw-r--r-- root/root 1312 2024-07-11 03:41 ./usr/share/man/fr/man5/sysctl.conf.5.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/fr/man8/ -rw-r--r-- root/root 2378 2024-07-11 03:41 ./usr/share/man/fr/man8/sysctl.8.gz
-rw-r--r-- root/root 2883 2024-07-11 03:41 ./usr/share/man/fr/man8/vmstat.8.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/man1/ -rw-r--r-- root/root 2000 2024-07-11 03:41 ./usr/share/man/man1/free.1.gz -rw-r--r-- root/root 1515 2024-07-11 03:41 ./usr/share/man/man1/kill.1.gz -rw-r--r-- root/root 3186 2024-07-11 03:41 ./usr/share/man/man1/pgrep.1.gz -rw-r--r-- root/root 1178 2024-07-11 03:41 ./usr/share/man/man1/pmap.1.gz -rw-r--r-- root/root 15307 2024-07-11 03:41 ./usr/share/man/man1/ps.1.gz -rw-r--r-- root/root 632 2024-07-11 03:41 ./usr/share/man/man1/pwdx.1.gz -rw-r--r-- root/root 1644 2024-07-11 03:41 ./usr/share/man/man1/skill.1.gz -rw-r--r-- root/root 1760 2024-07-11 03:41 ./usr/share/man/man1/slabtop.1.gz
-rw-r--r-- root/root 959 2024-07-11 03:41 ./usr/share/man/man1/tload.1.gz -rw-r--r-- root/root 33810 2024-07-11 03:41 ./usr/share/man/man1/top.1.gz -rw-r--r-- root/root 1123 2024-07-11 03:41 ./usr/share/man/man1/uptime.1.gz
-rw-r--r-- root/root 1569 2024-07-11 03:41 ./usr/share/man/man1/w.1.gz -rw-r--r-- root/root 2658 2024-07-11 03:41 ./usr/share/man/man1/watch.1.gz drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/man3/ -rw-r--r-- root/root 2692 2024-07-11 03:41 ./usr/share/man/man3/procps.3.gz
-rw-r--r-- root/root 1924 2024-07-11 03:41 ./usr/share/man/man3/procps_misc.3.gz
-rw-r--r-- root/root 3105 2024-07-11 03:41 ./usr/share/man/man3/procps_pids.3.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/man5/ -rw-r--r-- root/root 1171 2024-07-11 03:41 ./usr/share/man/man5/sysctl.conf.5.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/man8/ -rw-r--r-- root/root 2194 2024-07-11 03:41 ./usr/share/man/man8/sysctl.8.gz
-rw-r--r-- root/root 2444 2024-07-11 03:41 ./usr/share/man/man8/vmstat.8.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/pl/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/pl/man1/ -rw-r--r-- root/root 2304 2024-07-11 03:41 ./usr/share/man/pl/man1/free.1.gz
-rw-r--r-- root/root 3798 2024-07-11 03:41 ./usr/share/man/pl/man1/pgrep.1.gz
-rw-r--r-- root/root 1376 2024-07-11 03:41 ./usr/share/man/pl/man1/pmap.1.gz
-rw-r--r-- root/root 1295 2024-07-11 03:41 ./usr/share/man/pl/man1/uptime.1.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/pl/man3/ -rw-r--r-- root/root 2998 2024-07-11 03:41 ./usr/share/man/pl/man3/procps.3.gz
-rw-r--r-- root/root 2131 2024-07-11 03:41 ./usr/share/man/pl/man3/procps_misc.3.gz
-rw-r--r-- root/root 3422 2024-07-11 03:41 ./usr/share/man/pl/man3/procps_pids.3.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/pl/man8/ -rw-r--r-- root/root 2870 2024-07-11 03:41 ./usr/share/man/pl/man8/vmstat.8.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/pt_BR/ drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/pt_BR/man1/ -rw-r--r-- root/root 2231 2024-07-11 03:41 ./usr/share/man/pt_BR/man1/free.1.gz
-rw-r--r-- root/root 1688 2024-07-11 03:41 ./usr/share/man/pt_BR/man1/kill.1.gz
-rw-r--r-- root/root 1319 2024-07-11 03:41 ./usr/share/man/pt_BR/man1/pmap.1.gz
-rw-r--r-- root/root 723 2024-07-11 03:41 ./usr/share/man/pt_BR/man1/pwdx.1.gz
-rw-r--r-- root/root 1855 2024-07-11 03:41 ./usr/share/man/pt_BR/man1/skill.1.gz
-rw-r--r-- root/root 2001 2024-07-11 03:41 ./usr/share/man/pt_BR/man1/slabtop.1.gz
-rw-r--r-- root/root 1087 2024-07-11 03:41 ./usr/share/man/pt_BR/man1/tload.1.gz
-rw-r--r-- root/root 1310 2024-07-11 03:41 ./usr/share/man/pt_BR/man1/uptime.1.gz
-rw-r--r-- root/root 1751 2024-07-11 03:41 ./usr/share/man/pt_BR/man1/w.1.gz
-rw-r--r-- root/root 3076 2024-07-11 03:41 ./usr/share/man/pt_BR/man1/watch.1.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/pt_BR/man5/ -rw-r--r-- root/root 1335 2024-07-11 03:41 ./usr/share/man/pt_BR/man5/sysctl.conf.5.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/pt_BR/man8/ -rw-r--r-- root/root 2431 2024-07-11 03:41 ./usr/share/man/pt_BR/man8/sysctl.8.gz
-rw-r--r-- root/root 2763 2024-07-11 03:41 ./usr/share/man/pt_BR/man8/vmstat.8.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/ro/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/ro/man1/ -rw-r--r-- root/root 2423 2024-07-11 03:41 ./usr/share/man/ro/man1/free.1.gz
-rw-r--r-- root/root 1794 2024-07-11 03:41 ./usr/share/man/ro/man1/kill.1.gz
-rw-r--r-- root/root 3858 2024-07-11 03:41 ./usr/share/man/ro/man1/pgrep.1.gz
-rw-r--r-- root/root 1519 2024-07-11 03:41 ./usr/share/man/ro/man1/pidof.1.gz
-rw-r--r-- root/root 1352 2024-07-11 03:41 ./usr/share/man/ro/man1/pmap.1.gz
-rw-r--r-- root/root 17644 2024-07-11 03:41 ./usr/share/man/ro/man1/ps.1.gz -rw-r--r-- root/root 757 2024-07-11 03:41 ./usr/share/man/ro/man1/pwdx.1.gz
-rw-r--r-- root/root 1918 2024-07-11 03:41 ./usr/share/man/ro/man1/skill.1.gz
-rw-r--r-- root/root 2107 2024-07-11 03:41 ./usr/share/man/ro/man1/slabtop.1.gz
-rw-r--r-- root/root 1147 2024-07-11 03:41 ./usr/share/man/ro/man1/tload.1.gz
-rw-r--r-- root/root 40395 2024-07-11 03:41 ./usr/share/man/ro/man1/top.1.gz
-rw-r--r-- root/root 1342 2024-07-11 03:41 ./usr/share/man/ro/man1/uptime.1.gz
-rw-r--r-- root/root 1814 2024-07-11 03:41 ./usr/share/man/ro/man1/w.1.gz -rw-r--r-- root/root 3190 2024-07-11 03:41 ./usr/share/man/ro/man1/watch.1.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/ro/man3/ -rw-r--r-- root/root 3122 2024-07-11 03:41 ./usr/share/man/ro/man3/procps.3.gz
-rw-r--r-- root/root 2231 2024-07-11 03:41 ./usr/share/man/ro/man3/procps_misc.3.gz
-rw-r--r-- root/root 3636 2024-07-11 03:41 ./usr/share/man/ro/man3/procps_pids.3.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/ro/man5/ -rw-r--r-- root/root 1355 2024-07-11 03:41 ./usr/share/man/ro/man5/sysctl.conf.5.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/ro/man8/ -rw-r--r-- root/root 2542 2024-07-11 03:41 ./usr/share/man/ro/man8/sysctl.8.gz
-rw-r--r-- root/root 2873 2024-07-11 03:41 ./usr/share/man/ro/man8/vmstat.8.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/sv/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/sv/man1/ -rw-r--r-- root/root 2210 2024-07-11 03:41 ./usr/share/man/sv/man1/free.1.gz
-rw-r--r-- root/root 1658 2024-07-11 03:41 ./usr/share/man/sv/man1/kill.1.gz
-rw-r--r-- root/root 3494 2024-07-11 03:41 ./usr/share/man/sv/man1/pgrep.1.gz
-rw-r--r-- root/root 1378 2024-07-11 03:41 ./usr/share/man/sv/man1/pidof.1.gz
-rw-r--r-- root/root 1335 2024-07-11 03:41 ./usr/share/man/sv/man1/pmap.1.gz
-rw-r--r-- root/root 16504 2024-07-11 03:41 ./usr/share/man/sv/man1/ps.1.gz -rw-r--r-- root/root 762 2024-07-11 03:41 ./usr/share/man/sv/man1/pwdx.1.gz
-rw-r--r-- root/root 1836 2024-07-11 03:41 ./usr/share/man/sv/man1/skill.1.gz
-rw-r--r-- root/root 1973 2024-07-11 03:41 ./usr/share/man/sv/man1/slabtop.1.gz
-rw-r--r-- root/root 1125 2024-07-11 03:41 ./usr/share/man/sv/man1/tload.1.gz
-rw-r--r-- root/root 36740 2024-07-11 03:41 ./usr/share/man/sv/man1/top.1.gz
-rw-r--r-- root/root 1305 2024-07-11 03:41 ./usr/share/man/sv/man1/uptime.1.gz
-rw-r--r-- root/root 1749 2024-07-11 03:41 ./usr/share/man/sv/man1/w.1.gz -rw-r--r-- root/root 2921 2024-07-11 03:41 ./usr/share/man/sv/man1/watch.1.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/sv/man3/ -rw-r--r-- root/root 2915 2024-07-11 03:41 ./usr/share/man/sv/man3/procps.3.gz
-rw-r--r-- root/root 2106 2024-07-11 03:41 ./usr/share/man/sv/man3/procps_misc.3.gz
-rw-r--r-- root/root 3360 2024-07-11 03:41 ./usr/share/man/sv/man3/procps_pids.3.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/sv/man5/ -rw-r--r-- root/root 1329 2024-07-11 03:41 ./usr/share/man/sv/man5/sysctl.conf.5.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/sv/man8/ -rw-r--r-- root/root 2399 2024-07-11 03:41 ./usr/share/man/sv/man8/sysctl.8.gz
-rw-r--r-- root/root 2702 2024-07-11 03:41 ./usr/share/man/sv/man8/vmstat.8.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/uk/
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/uk/man1/ -rw-r--r-- root/root 3008 2024-07-11 03:41 ./usr/share/man/uk/man1/free.1.gz
-rw-r--r-- root/root 2166 2024-07-11 03:41 ./usr/share/man/uk/man1/kill.1.gz
-rw-r--r-- root/root 4628 2024-07-11 03:41 ./usr/share/man/uk/man1/pgrep.1.gz
-rw-r--r-- root/root 1909 2024-07-11 03:41 ./usr/share/man/uk/man1/pidof.1.gz
-rw-r--r-- root/root 1690 2024-07-11 03:41 ./usr/share/man/uk/man1/pmap.1.gz
-rw-r--r-- root/root 20176 2024-07-11 03:41 ./usr/share/man/uk/man1/ps.1.gz -rw-r--r-- root/root 908 2024-07-11 03:41 ./usr/share/man/uk/man1/pwdx.1.gz
-rw-r--r-- root/root 2384 2024-07-11 03:41 ./usr/share/man/uk/man1/skill.1.gz
-rw-r--r-- root/root 2674 2024-07-11 03:41 ./usr/share/man/uk/man1/slabtop.1.gz
-rw-r--r-- root/root 1415 2024-07-11 03:41 ./usr/share/man/uk/man1/tload.1.gz
-rw-r--r-- root/root 46431 2024-07-11 03:41 ./usr/share/man/uk/man1/top.1.gz
-rw-r--r-- root/root 1660 2024-07-11 03:41 ./usr/share/man/uk/man1/uptime.1.gz
-rw-r--r-- root/root 2305 2024-07-11 03:41 ./usr/share/man/uk/man1/w.1.gz -rw-r--r-- root/root 3827 2024-07-11 03:41 ./usr/share/man/uk/man1/watch.1.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/uk/man3/ -rw-r--r-- root/root 3707 2024-07-11 03:41 ./usr/share/man/uk/man3/procps.3.gz
-rw-r--r-- root/root 2646 2024-07-11 03:41 ./usr/share/man/uk/man3/procps_misc.3.gz
-rw-r--r-- root/root 4232 2024-07-11 03:41 ./usr/share/man/uk/man3/procps_pids.3.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/uk/man5/ -rw-r--r-- root/root 1637 2024-07-11 03:41 ./usr/share/man/uk/man5/sysctl.conf.5.gz
drwxr-xr-x root/root 0 2024-07-11 03:41 ./usr/share/man/uk/man8/ -rw-r--r-- root/root 3037 2024-07-11 03:41 ./usr/share/man/uk/man8/sysctl.8.gz
-rw-r--r-- root/root 3662 2024-07-11 03:41 ./usr/share/man/uk/man8/vmstat.8.gz
lrwxrwxrwx root/root 0 2024-07-11 03:41 ./usr/bin/pkill -> pgrep lrwxrwxrwx root/root 0 2024-07-11 03:41 ./usr/bin/snice -> skill lrwxrwxrwx root/root 0 2024-07-11 03:41 ./usr/share/man/man1/pidwait.1.gz -> pgrep.1.gz
lrwxrwxrwx root/root 0 2024-07-11 03:41 ./usr/share/man/man1/pkill.1.gz -> pgrep.1.gz
lrwxrwxrwx root/root 0 2024-07-11 03:41 ./usr/share/man/man1/snice.1.gz -> skill.1.gz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-29 23:36:02 -0500, David Wright wrote:

On Mon 29 Jul 2024 at 11:24:25 (+0200), Vincent Lefevre wrote:

On 2024-07-28 22:26:10 -0500, David Wright wrote:

On Sun 28 Jul 2024 at 16:43:01 (+0200), Vincent Lefevre wrote:

On 2024-07-28 00:07:56 -0500, David Wright wrote:

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

I only wrote that the /order/ was accidental:

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.

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

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

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.

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?

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.

[...]

(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!!!

--
Vincent Lef�vre <[email protected]> - 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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Aug 01, 2024 at 14:47:16 +0200, Vincent Lefevre wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Thu, Aug 01, 2024 at 09:37:54AM -0400, Greg Wooledge wrote:

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

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-01 09:37:54 -0400, Greg Wooledge wrote:

On Thu, Aug 01, 2024 at 14:47:16 +0200, Vincent Lefevre wrote:

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.

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.

--
Vincent Lef�vre <[email protected]> - 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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Vincent Lefevre (12024-08-01):

so the silent breakage was known and done on purpose.

Cutting yourself on Hanlon's Razor.

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Aug 01, 2024 at 16:03:32 +0200, Vincent Lefevre wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Do, Aug 01, 2024 at 14:08:21 +0000 schrieb 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

--
| If your life was a horse, you'd have to shoot it. |

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andy Smith wrote:

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-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, 02-08-2024 at 02:39 Dan Ritter wrote:

Andy Smith wrote:

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.

-dsr-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-01 23:17:42 -0400, Jeffrey Walton wrote:

The reference also says:

Only pure stable release with security updates provides the best
stability.

But stable does not mean bugless. Unfortunately stable sometimes
has major bugs, and the only thing to do is to wait for the next
stable release (except when one is the admin, in which case, one
can patch the software and recompile).

--
Vincent Lef�vre <[email protected]> - 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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)