Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #84279 > unrolled thread
| Started by | sergio <sergio+it@outerface.net> |
|---|---|
| First post | 2024-10-15 18:30 +0200 |
| Last post | 2024-11-25 00:30 +0100 |
| Articles | 10 — 5 participants |
Back to article view | Back to linux.debian.kernel
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
| From | sergio <sergio+it@outerface.net> |
|---|---|
| Date | 2024-10-15 18:30 +0200 |
| Subject | Bug#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]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2024-10-18 23:10 +0200 |
| Subject | Processed: 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]
| From | Noah Meyerhans <noahm@debian.org> |
|---|---|
| Date | 2024-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]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2024-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]
| From | Craig Small <csmall@debian.org> |
|---|---|
| Date | 2024-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]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2024-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]
| From | Craig Small <csmall@debian.org> |
|---|---|
| Date | 2024-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]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2024-10-24 02:10 +0200 |
| Subject | Processed: 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]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2024-11-25 00:30 +0100 |
| Subject | Processed: 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]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2024-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