OpenRC supports both /etc/sysctl.conf and /etc/sysctl.d/*.conf, with the latter taking precedence. systemd supported both up to -206, with the former taking precedence. As of -207, systemd no longer supports /etc/sysctl.conf and suggests symlinking that file to /etc/sysctl.d/99-sysctl.conf. Considering that the order is a bit inconsistent here and sysctl.d is commonly supported, how about making baselayout install sysctl.d/99-*.conf instead of /etc/sysctl.conf?
Honestly, its getting a bit old that every random version of systemd is breaking backwards compat with something just for the sake of change. Why don't we have systemd create a symlink to /etc/sysctl.conf and be done with it?
Just wondering. There's still the issue that OpenRC reads /etc/sysctl.conf before sysctl.d.
If any changes are to be made to /etc/init.d/sysctl, I would suggest calling sysctl --system, or emulating its behavior for backward compat. From sysctl(8): --system Load settings from all system configuration files. /run/sysctl.d/*.conf /etc/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf
> getting a bit old that every random version of systemd is breaking backwards It is an attempt of upstream Systemd to get sanity regarding precedence. @Mike Gilberts excerpt of the man shows the problem lies in sequence. Surely you would like to have resultend sysctl values from /etc - not just distribution /usr/lib values. And thus linking /etc/sysctl.conf into /etc/sysctl.d: What number preceding?
(In reply to Mike Gilbert from comment #3) > If any changes are to be made to /etc/init.d/sysctl, I would suggest calling > sysctl --system, or emulating its behavior for backward compat. This I could probably do in OpenRc easily enough without affecting baselayout. Is this the way we should go?
Created attachment 382426 [details, diff] 0001-sysctl.linux.in-use-the-system-option.patch This is the way I would propose fixing this issue in OpenRc. Any thoughts?
(In reply to William Hubbs from comment #6) Seems fine to me, though I have not tested it.
This is pushed in OpenRC in commit d29db70, which will be included in OpenRC-0.13. Now, I have a question for the rest of the baselayout maintainers. Should we move /etc/sysctl.conf to /etc/sysctl.d/00baselayout.conf in the next baselayout release?
(In reply to William Hubbs from comment #8) > This is pushed in OpenRC in commit d29db70, which will be included in > OpenRC-0.13. FYI, this changed the parse order of the config files. Previously openrc read: /etc/sysctl.conf /etc/sysctl.d/*.conf By using --system, the order is inverted: /etc/sysctl.d/*.conf /etc/sysctl.conf (plus whatever /run, /lib directories). This broke my configuration since I had expected the first behavior and was using files in sysctl.d as overrides to whatever defaults were installed by portage in /etc/sysctl.conf. Now my overrides are overridden by the defaults.
(In reply to Robert Trace from comment #9) > (In reply to William Hubbs from comment #8) > > This is pushed in OpenRC in commit d29db70, which will be included in > > OpenRC-0.13. > > FYI, this changed the parse order of the config files. Previously openrc > read: > > /etc/sysctl.conf > /etc/sysctl.d/*.conf > > By using --system, the order is inverted: > > /etc/sysctl.d/*.conf > /etc/sysctl.conf > > (plus whatever /run, /lib directories). > > This broke my configuration since I had expected the first behavior and was > using files in sysctl.d as overrides to whatever defaults were installed by > portage in /etc/sysctl.conf. > > Now my overrides are overridden by the defaults. Me too! Any solution on the horizon?
(In reply to William Hubbs from comment #8) > Now, I have a question for the rest of the baselayout maintainers. > > Should we move /etc/sysctl.conf to /etc/sysctl.d/00baselayout.conf in > the next baselayout release? I'm not a maintainer, but this seems like a reasonable course of action to me.
Created attachment 402152 [details, diff] fix for busybox sysctl the sysctl --system option is not supported by busybox sysctl. The attached patch has a suggestion that should do same thing and make it easy to reorder the preference.
Hi all, There may still be reason to ressurrect this. /usr/sbin/sysctl on my system at least is owned by procps. The init script /etc/init.d/sysctl however belongs to openrc. I'm not using systemd. Looking at the init script there are two variants, the BSD variant, which runs when RC_UNAME is *BSD|GNU. The BSD variant seems confusing to say the least, so I'm going to assume it's required and sane/correct. From the sysctl man page: --system Load settings from all system configuration files. /run/sysctl.d/*.conf /etc/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf I can also confirm that that's the order. The default /etc/sysctl.conf contains some settings I'd like to override by dropping files into /etc/sysctl.d/*.conf. /run sits on ramdisk so we should probably avoid dropping things there, and seeing that users will likely only ever drop files in /etc/sysctl.d/ (or edit /etc/sysctl.conf) the order of loading makes no sense whatsoever to me personally (I'd reverse the order exactly, first system defaults, then /*/lib/sysctl.d overrides, then /etc/sysctl.d/ ones - administrator, and lastly /run/sysctl.d/ - sits on ram disk, volatile). Motivation should be simple: Enable the user to avoid ever having to edit /etc/sysctl.conf - we install a large number of systems and generally prefer just dropping files into the right locations as part of a custom package rather than having to modify config files wherever possible. Given the constraints (modifying procps might be the right thing to do, but I'm not so sure and would create inconsistency, and as per other complaints to just change things for the sake of changing it is counter-productive, I agree, especially when it's just patching upstream software for the sake of it). As per earlier comments the problem with --system is precedence. The proposed fix for busybox might be the way to go. But that would change (and quite possibly break things for existing systems). Another route to go, is to remove /etc/sysctl.conf completely and instead use ONLY files in /etc/sysctl.d/ - the problem then becomes - do we install the current sysctl.conf as 00-system-defualts.conf (logically sane) or 99-system-defaults.conf (emulating current behaviour). I'd appreciate some additional insights into this, and discussion towards a better solution, my proposal would be: 1. install the system default as /etc/sysctl.d/00-system-defaults.conf 2. If during installation (pkg_pre/postinst?) if /etc/sysctl.conf exists (and not /etc/sysctl.d/99-sysctl.conf), move it to /etc/sysctl.d/99-sysctl.conf - possibly replacing it with an empty file warning to rather edit files under /etc/sysctl.d/. Seeing that /etc/sysctl.conf belongs to sys-apps/baselayout this would require changes to baselayout. As a side effect, if a user does insist on creating a /etc/sysctl.conf hereafter that would take precedence over the newly created structure in /etc/sysctl.d/ which is probably fair, even though in a normal context where .d folders are processed post-main counter-intuitive.
I want to set net.ipv4.ip_forward to 1, and /etc/sysctl.conf from baselayout sets it to 0. This means whenever baselayout is upgraded, I have to execute dispatch-conf. I think /etc/sysctl.conf just adds more hassle. It should be moved where it has lower precedence than other files in /etc/sysctl.d
After moving /etc/sysctl.conf to /etc/sysctl.d/00baselayout.conf, /etc/sysctl.d/local.conf will override /etc/sysctl.d/00baselayout.conf
(In reply to crocket from comment #15) > After moving /etc/sysctl.conf to /etc/sysctl.d/00baselayout.conf, > /etc/sysctl.d/local.conf will override /etc/sysctl.d/00baselayout.conf I'd like to see it go away altogether. As you pointed out, it contains "net.ipv4.ip_forward = 0", which is a nuisance and is only re-asserting a kernel default. Otherwise, it contains a selection of commented examples that some developer happened to find personally interesting way back when, with no apparent rhyme or reason. Even some of those are just spelling out the kernel defaults, such as "net.ipv4.tcp_syncookies = 1" and "net.ipv4.icmp_echo_ignore_broadcasts = 1". In its current form, it doesn't offer any discernible value. Like you, I suppress it but wouldn't want it turning up in /etc/sysctl.d either. I prefer the way Arch does it. There is no /etc/sysctl.conf unless the user elects to create one. As a vendor, they only deem it necessary to change two settings - relaxing inotify-related resource limits - which is done by way of /usr/lib/sysctl.d/10-arch.conf (and I doubt they would have done unless they felt it was in the public interest). All of which leaves /etc nice and clean for the user to do with as they wish. Now, should the user want to override those specific changes, they have the option of creating /etc/sysctl.conf, given that it is parsed last. Alternatively, should they wish to disable the vendor settings outright, whatever they may be, they have the option of running `cd /etc/sysctl.d && ln -s /dev/null 10-arch.conf`. It works because, once a file of a given name has been parsed by sysctl --system, any file of the same name that is seen in a directory that is traversed later is skipped.
I think dropping /etc/sysctl.conf from baselayout is a good idea.
(In reply to Mike Gilbert from comment #17) > I think dropping /etc/sysctl.conf from baselayout is a good idea. Thanks. I realise that this isn't the exact issue under discussion but it occurs to me there is also an opportunity to get one's ducks in a row, regarding how packages should install sysctl.d snippets. There aren't many that do this but, of those that exist, some install to /etc/sysctl.d while others install to /usr/lib/sysctl.d. It ought to be one or the other and I would suggest the latter. For one thing, because it's intended as a vendor directory but also because it's then possible to override entire snippets by creating a file of the same name under /etc/sysctl.d or to effectively disable it by touching it or linking to /dev/null (rather like with udev). This isn't possible in any case where /etc/sysctl.d is being treated as a vendor directory.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/baselayout.git/commit/?id=782d0ded97da543c216baf2a9852423744e20549 commit 782d0ded97da543c216baf2a9852423744e20549 Author: William Hubbs <williamh@gentoo.org> AuthorDate: 2021-09-24 17:04:35 +0000 Commit: William Hubbs <williamh@gentoo.org> CommitDate: 2021-09-24 17:15:14 +0000 drop sysctl.conf for Linux systems This file is no longer needed. All of the settings are kernel defaults. Closes: https://bugs.gentoo.org/484796 Signed-off-by: William Hubbs <williamh@gentoo.org> etc.Linux/sysctl.conf | 60 --------------------------------------------------- 1 file changed, 60 deletions(-)
(In reply to Kerin Millar from comment #18) I agree that it would be good to have some consistency here. I would suggest filing separate bugs to ask package maintainers to move sysctl.d files from /etc/sysctl.d to /usr/lib/sysctl.d.
