Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #84279 > unrolled thread

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

Started bysergio <sergio+it@outerface.net>
First post2024-10-15 18:30 +0200
Last post2024-11-25 00:30 +0100
Articles 10 — 5 participants

Back to article view | Back to linux.debian.kernel


Contents

  Bug#1085160: linux-sysctl-defaults: apply setting after installation sergio <sergio+it@outerface.net> - 2024-10-15 18:30 +0200
    Processed: Re: Bug#1085160: linux-sysctl-defaults: apply setting  after installation "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-10-18 23:10 +0200
    Bug#1085160: linux-sysctl-defaults: apply setting after installation Noah Meyerhans <noahm@debian.org> - 2024-10-18 23:10 +0200
    Bug#1085160: linux-sysctl-defaults: apply setting after installation Ben Hutchings <ben@decadent.org.uk> - 2024-10-24 02:10 +0200
      Bug#1085160: linux-sysctl-defaults: apply setting after installation Craig Small <csmall@debian.org> - 2024-10-24 12:30 +0200
        Bug#1085160: linux-sysctl-defaults: apply setting after installation Ben Hutchings <ben@decadent.org.uk> - 2024-10-30 20:10 +0100
          Bug#1085160: linux-sysctl-defaults: apply setting after installation Craig Small <csmall@debian.org> - 2024-11-04 11:50 +0100
    Processed: Re: Bug#1085160: linux-sysctl-defaults: apply setting  after installation "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-10-24 02:10 +0200
    Processed: Re: linux-sysctl-defaults: apply setting after  installation "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-11-25 00:30 +0100
    Bug#1085160: linux-sysctl-defaults: apply setting after installation Ben Hutchings <ben@decadent.org.uk> - 2024-11-25 00:30 +0100

#84279 — Bug#1085160: linux-sysctl-defaults: apply setting after installation

Fromsergio <sergio+it@outerface.net>
Date2024-10-15 18:30 +0200
SubjectBug#1085160: linux-sysctl-defaults: apply setting after installation
Message-ID<JxSAN-1Pjy-3@gated-at.bofh.it>
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

[toc] | [next] | [standalone]


#84292 — Processed: Re: Bug#1085160: linux-sysctl-defaults: apply setting after installation

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2024-10-18 23:10 +0200
SubjectProcessed: Re: Bug#1085160: linux-sysctl-defaults: apply setting after installation
Message-ID<Jz2op-2xh7-7@gated-at.bofh.it>
In reply to#84279
Processing control commands:

> severity -1 important
Bug #1085160 [linux-sysctl-defaults] linux-sysctl-defaults: apply setting after installation
Severity set to 'important' from 'normal'
> affects -1 iputils-ping
Bug #1085160 [linux-sysctl-defaults] linux-sysctl-defaults: apply setting after installation
Added indication that 1085160 affects iputils-ping

-- 
1085160: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085160
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]


#84293

FromNoah Meyerhans <noahm@debian.org>
Date2024-10-18 23:10 +0200
Message-ID<Jz2op-2xh7-5@gated-at.bofh.it>
In reply to#84279
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

[toc] | [prev] | [next] | [standalone]


#84348

FromBen Hutchings <ben@decadent.org.uk>
Date2024-10-24 02:10 +0200
Message-ID<JATAl-3MZc-1@gated-at.bofh.it>
In reply to#84279

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]


#84353

FromCraig Small <csmall@debian.org>
Date2024-10-24 12:30 +0200
Message-ID<JB3gm-3SMN-3@gated-at.bofh.it>
In reply to#84348

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]


#84405

FromBen Hutchings <ben@decadent.org.uk>
Date2024-10-30 20:10 +0100
Message-ID<JDmeR-5qBG-17@gated-at.bofh.it>
In reply to#84353

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]


#84435

FromCraig Small <csmall@debian.org>
Date2024-11-04 11:50 +0100
Message-ID<JF2OK-6y5W-25@gated-at.bofh.it>
In reply to#84405

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]


#84349 — Processed: Re: Bug#1085160: linux-sysctl-defaults: apply setting after installation

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2024-10-24 02:10 +0200
SubjectProcessed: Re: Bug#1085160: linux-sysctl-defaults: apply setting after installation
Message-ID<JATAl-3MZc-3@gated-at.bofh.it>
In reply to#84279
Processing control commands:

> tag -1 moreinfo
Bug #1085160 [linux-sysctl-defaults] linux-sysctl-defaults: apply setting after installation
Added tag(s) moreinfo.

-- 
1085160: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085160
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]


#84663 — Processed: Re: linux-sysctl-defaults: apply setting after installation

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2024-11-25 00:30 +0100
SubjectProcessed: Re: linux-sysctl-defaults: apply setting after installation
Message-ID<JMudb-blbD-9@gated-at.bofh.it>
In reply to#84279
Processing control commands:

> tag -1 patch
Bug #1085160 [linux-sysctl-defaults] linux-sysctl-defaults: apply setting after installation
Added tag(s) patch.

-- 
1085160: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085160
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]


#84664

FromBen Hutchings <ben@decadent.org.uk>
Date2024-11-25 00:30 +0100
Message-ID<JMudb-blbD-11@gated-at.bofh.it>
In reply to#84279

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web