Debian Bug report logs - #1085160
linux-sysctl-defaults: apply setting after installation

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: sergio <sergio+it@outerface.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: linux-sysctl-defaults: apply setting after installation

Date: Tue, 15 Oct 2024 19:04:51 +0300

Package: linux-sysctl-defaults
Version: 4.10.1
Severity: normal

Dear Maintainer,

please call `sysctl -p /usr/lib/sysctl.d/50-default.conf` after installation

Message #10 received at 1085160@bugs.debian.org (full text, mbox, reply):

From: Noah Meyerhans <noahm@debian.org>

To: sergio <sergio+it@outerface.net>, 1085160@bugs.debian.org

Subject: Re: Bug#1085160: linux-sysctl-defaults: apply setting after installation

Date: Fri, 18 Oct 2024 16:57:04 -0400

Control: severity -1 important
Control: affects -1 iputils-ping

On Tue, Oct 15, 2024 at 07:04:51PM +0300, sergio wrote:
> please call `sysctl -p /usr/lib/sysctl.d/50-default.conf` after installation

+1  Not doing so is leading to confusing/broken behavior during
upgrades.  By deferring the application of the sysctl settings until
reboot, we're effectively leaving the system in a half-upgraded state
where applications that depend on sysctls set here will misbehave for
confusing reasons until a reboot happens.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085289 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084135 for instances
of issues caused during upgrades.

noah

Message #19 received at 1085160@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: sergio <sergio+it@outerface.net>, Noah Meyerhans <noahm@debian.org>, Luca Boccassi <bluca@debian.org>, Craig Small <csmall@debian.org>

Cc: 1085160@bugs.debian.org

Subject: Re: Bug#1085160: linux-sysctl-defaults: apply setting after installation

Date: Thu, 24 Oct 2024 02:07:03 +0200

[Message part 1 (text/plain, inline)]

Control: tag -1 moreinfo

On Tue, 2024-10-15 at 19:04 +0300, sergio wrote:
> Package: linux-sysctl-defaults
> Version: 4.10.1
> Severity: normal
> 
> Dear Maintainer,
> 
> please call `sysctl -p /usr/lib/sysctl.d/50-default.conf` after installation

Running that command is definitely not a good idea, as it will ignore
any other configuration files which should override the default
settings.

This was discussed at
<https://salsa.debian.org/kernel-team/linux-base/-/merge_requests/12#note_500942>
and there was a deliberate decision then not to do this.

Noah Meyerhans wrote:
> +1  Not doing so is leading to confusing/broken behavior during
> upgrades.  By deferring the application of the sysctl settings until
> reboot, we're effectively leaving the system in a half-upgraded state
> where applications that depend on sysctls set here will misbehave for
> confusing reasons until a reboot happens.
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085289 and
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084135 for instances
> of issues caused during upgrades.

So it sounds like we do actually need to apply configuration on
installation, just not precisely as requested.

Looking at the postinst scripts of some other packages that install
sysctl configuration, I can see a diversity of approaches to this:

- bubblewrap runs "sysctl --pattern <sysctl-name>" which seems
  reasonable for a single sysctl but would be a pain to keep in sync
  with the configuration file.

- tracker-miner-fs runs "systemd-sysctl <filename>" which does not
  work without systemd and seems to have the same problem I mentioned
  above.

Whatever is decided for linux-sysctl-defaults should ideally be
implemented consistently across the other packages.

Would this work:

1. As discussed in the GitLab MR, systemd implements a file trigger on
   sysctl configuration files.

2. Either:
   (a) procps implements a similar trigger, but makes it a no-op when
       systemd is pid 1.
   (b) linux-sysctl-defaults postinst does:
       - if systemd is pid 1, nothing;
       - otherwise, if sysctl is installed, "sysctl --system";
       - otherwise, nothing.

?

I don't know how well those file triggers would interact with existing
postinst scripts for the other packages.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                               A fail-safe circuit will destroy others.

[signature.asc (application/pgp-signature, inline)]

Message #26 received at 1085160@bugs.debian.org (full text, mbox, reply):

From: Craig Small <csmall@debian.org>

To: Ben Hutchings <ben@decadent.org.uk>

Cc: sergio <sergio+it@outerface.net>, Noah Meyerhans <noahm@debian.org>, Luca Boccassi <bluca@debian.org>, 1085160@bugs.debian.org

Subject: Re: Bug#1085160: linux-sysctl-defaults: apply setting after installation

Date: Thu, 24 Oct 2024 21:09:29 +1100

[Message part 1 (text/plain, inline)]

On Thu, 24 Oct 2024 at 11:25, Ben Hutchings <ben@decadent.org.uk> wrote:

>
> 1. As discussed in the GitLab MR, systemd implements a file trigger on
>    sysctl configuration files.

I'm not seeing that. There are three triggers in systemd 256.6-1 but not
for sysctl files.
Wouldn't it be in
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/systemd.triggers?ref_type=heads

2. Either:
>    (a) procps implements a similar trigger, but makes it a no-op when
>        systemd is pid 1.
>    (b) linux-sysctl-defaults postinst does:
>        - if systemd is pid 1, nothing;
>        - otherwise, if sysctl is installed, "sysctl --system";
>        - otherwise, nothing.
>
I agree that directly calling the specific file is a bad idea. A user may
have overrides in other files
which may not be caught up if you specify a file directly.

So there are a few things here:
 * A fix for linux-sysctl-defaults conf files
* Generically something for any package

If we're trying to do the first, then having something like your option b
seems a good idea.
The conf file and the postinst are the same package, so its simple. It is
actually what
#1085160 is about.

Should something, procps or linux-sysctl-defaults, be watching the sysctl.d
files
in their various locations and triggering a sysctl if they change? Or
should the
individual packages do it?

Should there be some small script that works out which sysctl to use?
If there is 'whatever-sysctl-is-here' script, where should it live?
Or would some wiki entry do it better?

 - Craig

[Message part 2 (text/html, inline)]

Message #31 received at 1085160@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Craig Small <csmall@debian.org>

Cc: sergio <sergio+it@outerface.net>, Noah Meyerhans <noahm@debian.org>, Luca Boccassi <bluca@debian.org>, 1085160@bugs.debian.org

Subject: Re: Bug#1085160: linux-sysctl-defaults: apply setting after installation

Date: Wed, 30 Oct 2024 19:56:33 +0100

[Message part 1 (text/plain, inline)]

On Thu, 2024-10-24 at 21:09 +1100, Craig Small wrote:
> On Thu, 24 Oct 2024 at 11:25, Ben Hutchings <ben@decadent.org.uk> wrote:
> 
> > 
> > 1. As discussed in the GitLab MR, systemd implements a file trigger on
> >    sysctl configuration files.
> 
> I'm not seeing that. There are three triggers in systemd 256.6-1 but not
> for sysctl files.
> Wouldn't it be in
> https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/systemd.triggers?ref_type=heads

This was a proposed action, not a statement of current behaviour.

> 2. Either:
> >    (a) procps implements a similar trigger, but makes it a no-op when
> >        systemd is pid 1.
> >    (b) linux-sysctl-defaults postinst does:
> >        - if systemd is pid 1, nothing;
> >        - otherwise, if sysctl is installed, "sysctl --system";
> >        - otherwise, nothing.
> > 
> I agree that directly calling the specific file is a bad idea. A user may
> have overrides in other files
> which may not be caught up if you specify a file directly.
> 
> So there are a few things here:
>  * A fix for linux-sysctl-defaults conf files
> * Generically something for any package
> 
> If we're trying to do the first, then having something like your option b
> seems a good idea.
> The conf file and the postinst are the same package, so its simple. It is
> actually what
> #1085160 is about.

Yes.  But the logic is not so straightforward that other packages
installing sysctl files have all done the same thing.  I would like to
start moving toward a consistent behaviour for such packages rather
than just adding another variant.

> Should something, procps or linux-sysctl-defaults, be watching the sysctl.d
> files
> in their various locations and triggering a sysctl if they change? Or
> should the
> individual packages do it?

I would prefer for procps to do it, since:

- systemd and procps are the only 2 packages that are able to parse and
apply these files.  If neither is installed then nothing can be done
with them, so there is little value in adding such a trigger elsewhere.

- linux-sysctl-defaults is currently optional, as it is only
recommended by systemd and procps.

> Should there be some small script that works out which sysctl to use?
> If there is 'whatever-sysctl-is-here' script, where should it live?
> Or would some wiki entry do it better?

This should be unnecessary if we use triggers.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[signature.asc (application/pgp-signature, inline)]

Message #36 received at 1085160@bugs.debian.org (full text, mbox, reply):

From: Craig Small <csmall@debian.org>

To: Ben Hutchings <ben@decadent.org.uk>

Cc: sergio <sergio+it@outerface.net>, Noah Meyerhans <noahm@debian.org>, Luca Boccassi <bluca@debian.org>, 1085160@bugs.debian.org

Subject: Re: Bug#1085160: linux-sysctl-defaults: apply setting after installation

Date: Mon, 4 Nov 2024 21:15:34 +1100

[Message part 1 (text/plain, inline)]

On Thu, 31 Oct 2024 at 05:56, Ben Hutchings <ben@decadent.org.uk> wrote:

> On Thu, 2024-10-24 at 21:09 +1100, Craig Small wrote:
> > I'm not seeing that. There are three triggers in systemd 256.6-1 but not
> > for sysctl files.
> > Wouldn't it be in
> >
> https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/systemd.triggers?ref_type=heads
>
> This was a proposed action, not a statement of current behaviour.
>
Ah ok, that's why I can't find them!


> - systemd and procps are the only 2 packages that are able to parse and
> apply these files.  If neither is installed then nothing can be done
> with them, so there is little value in adding such a trigger elsewhere.
>
On reflection, I agree. Both system and procps would have similiar triggers
because,
as you say, they're the only things that can do something about it.

I'm happy to work with the systemd developers to have a consistent set
of triggers across both packages. I'd expect the main difference besides
what
command is run is procps will need some sort of "is systemd running?" check.

I am concerned conceptually about setting kernel parameters while the
system is out
of boot phase. For example setting variables net.ipv4.conf.all/default will
do diferent things
due to network interfaces that exist, or will exist soon.

I don't see a fix for that; after all the issue this report is trying to
fix is we want these changes to immediately happen.

 - Craig

[Message part 2 (text/html, inline)]

Message #45 received at 1085160@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: 1085160@bugs.debian.org

Subject: Re: linux-sysctl-defaults: apply setting after installation

Date: Mon, 25 Nov 2024 00:21:54 +0100

[Message part 1 (text/plain, inline)]

Control: tag -1 patch

I've opened
<https://salsa.debian.org/systemd-team/systemd/-/merge_requests/279>
to add the necessary file trigger to systemd.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

[signature.asc (application/pgp-signature, inline)]

Message #60 received at 1085160-submitter@bugs.debian.org (full text, mbox, reply):

From: Luca Boccassi <noreply@salsa.debian.org>

To: 1085160-submitter@bugs.debian.org

Subject: Bug#1085160 marked as pending in systemd

Date: Mon, 25 Nov 2024 15:37:35 +0000

Control: tag -1 pending

Hello,

Bug #1085160 in systemd reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/systemd-team/systemd/-/commit/f2ddf70604920bc350c4f8aa7b895518d1808e33

------------------------------------------------------------------------
sysctl: Add file trigger on /usr/lib/sysctl.d to restart systemd-sysctl

As discussed in Debian bug #1085160, sysctl configuration files should be
applied on installation and upgrade.  Add a file trigger to make this happen
by restarting systemd-sysctl.service (if not masked).

Closes: #1085160
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1085160

Message #67 received at 1085160-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 1085160-close@bugs.debian.org

Subject: Bug#1085160: fixed in systemd 257~rc3-1

Date: Thu, 28 Nov 2024 00:50:58 +0000

[Message part 1 (text/plain, inline)]

Source: systemd
Source-Version: 257~rc3-1
Done: Luca Boccassi <bluca@debian.org>

We believe that the bug you reported is fixed in the latest version of
systemd, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1085160@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Luca Boccassi <bluca@debian.org> (supplier of updated systemd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Wed, 27 Nov 2024 21:21:02 +0000
Source: systemd
Architecture: source
Version: 257~rc3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>
Changed-By: Luca Boccassi <bluca@debian.org>
Closes: 1085160 1087808 1087817
Changes:
 systemd (257~rc3-1) unstable; urgency=medium
 .
   [ Luca Boccassi ]
   * systemd-ukify: recommend systemd-boot-efi for the stub (Closes:
     #1087808)
   * Increase minimum sections in stub PE header on arm64/armhf/riscv64 to
     500. Allows riscv64 to include all current DTBs with some room to grow
     (Closes: #1087817)
   * Bump version in tzdata dependency due to p-u upload
   * Update to new upstream version v257~rc3. For a full list of changes:
     https://github.com/systemd/systemd/releases/tag/v257-rc3
   * Drop patches, merged upstream
   * Update symbols for 257~rc3
 .
   [ Ben Hutchings ]
   * sysctl: Add file trigger on /usr/lib/sysctl.d to restart systemd-
     sysctl. (Closes: #1085160)
Checksums-Sha1:
 bdaf48eeb577ff48e19f0ec60c9b7762acc87c9b 8665 systemd_257~rc3-1.dsc
 07be65c6aa059a4d2b6d967e9e6dbff89a1f5359 16226197 systemd_257~rc3.orig.tar.gz
 5bbfabf2ff7d1c32ae3334a3a056743699a326a5 175832 systemd_257~rc3-1.debian.tar.xz
 90b062f00a5ae9352f3590af144eaea3e33cefdc 13934 systemd_257~rc3-1_source.buildinfo
Checksums-Sha256:
 a7340c356731febbaeec44f360932cc9f9b5b7bae025c494b1f74f00b1edcd96 8665 systemd_257~rc3-1.dsc
 bb0837988c3fb9b60d8ad38be791663a30cdb606242665f1157e1d884e2d892a 16226197 systemd_257~rc3.orig.tar.gz
 c068395d476f335812b83a72379072f04b4dd5a2edaff2e9ea149863db644a5b 175832 systemd_257~rc3-1.debian.tar.xz
 60c4bbdaf976d5b159a28d869734d66f6e7c45007d528ecde7f50abf50f075e9 13934 systemd_257~rc3-1_source.buildinfo
Files:
 fc70ab60c33b3752abac449e465bbfc9 8665 admin optional systemd_257~rc3-1.dsc
 65d0e8eaa0ccedd8694383efbb65c7cf 16226197 admin optional systemd_257~rc3.orig.tar.gz
 4b7891902108b4cfde47de7802bb4735 175832 admin optional systemd_257~rc3-1.debian.tar.xz
 b38f35ae8732161a728952cd9baf1806 13934 admin optional systemd_257~rc3-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJFBAEBCgAvFiEErCSqx93EIPGOymuRKGv37813JB4FAmdHt24RHGJsdWNhQGRl
Ymlhbi5vcmcACgkQKGv37813JB7+jA//T9EljT7FyPlSL/IwGPiIYUuyGdAxfCgb
ba0X1tK6jL0I2fmr44Mxg6Ir+WJh21OR552t5j5bH9+CFsSqEmyHPXzx9x9yKpC2
Zps3nQYKgGi/nxIJ11evweW1Nf0RP4AA+S3P14+NXHXR1HfIfve28w1CHeUTd+Zc
4TT5qeYMPAKs5gBzkRsWJwof2zjTnDA4N/hscUWlU+5vFMKcVwKR4VRuwg+6kpNU
qpXuLlQSEo+kM3fnNdecPVRyGzwP/+E12skqMUCcc2lNJUghMLtwQ3vlRxNxgIke
bgKaHHMb2k4rYeVKeyNtWCnDMyd5ylzKt9aBboK3SDFARbUoXYdoThsQxN7IouIq
nXne5nd57B+1LXuzMnReT8knYI3ZTxsXaEbpwq8MoshBME8iDTqlKyVRKrtn74Vn
GBlX+uIe/88cjMimteX7qihUgZr/sD9tyCDVDzf3jkCiteazhbDzTrvqbdFV4RT8
J1kltW7C3YdIEoa8O8CMLfJfnvwANLY17Fpyw0PgoA5FfHu5SZldWlj//9ahBHvE
1NDTDPjGalnI2RMW9baerxysBgZxRUB+9dzMy2i2OvtUQPLcOh7as71mJ+Q2dAmm
Lp9GO6y/zwG9V+T3NJ46pozu++LZR4mDTQGI47U7PwO0VFhVJwvwzBC/gbspeMyu
L3K6k8gBBa8=
=wQpn
-----END PGP SIGNATURE-----

[Message part 2 (application/pgp-signature, inline)]

Send a report that this bug log contains spam.