On Thu, 2024-10-24 at 21:09 +1100, Craig Small wrote: > On Thu, 24 Oct 2024 at 11:25, Ben Hutchings <b...@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
Description: This is a digitally signed message part