Hi Josh, On Sun, Apr 23, 2017 at 10:48:33AM -0700, Josh Triplett wrote: > Evgeni Golov wrote: > > LXC recently got a bug (#860974) that is best fixed by bumping a certain > > sysctl limit above the default. > > Note that in addition to going this route, you might consider talking with the > kernel maintainers about increasing the default limit, or potentially even > getting the limit raised upstream.
This *specific* issue should go away as soon as we have user-ns aware inotify counters [1], so it's thankfully just a temporary band-aid. > > However I could not find any documented policy how to do this (if at all). > > > > Both, procps and systemd support (/usr)?/lib/sysctl.d/*.conf, however only > > one package (systemd-coredump) uses it, all others drop files in > > /etc/sysctl.d. > > > > Some packages also trigger "sysctl -q -p <file>" in their postinst, but > > most do not. > > > > My gut feeling is that droping the file to /usr/lib and allowing the admin > > to override it later via /etc. And then load it in postinst. > > That seems like exactly the right approach, and yes, you should put it > in /usr/lib/50-yourpackagename.conf , following the conventions > explicitly established for that purpose. Do you have a pointer to the conventions? Neither /etc/sysctl.d/README.sysctl, nor sysctl.conf(5) or sysctl.d(5) have anything on naming, besides "*.conf". And the current in-archive packages are not telling much either: % apt-file search sysctl.d bit-babbler: /etc/sysctl.d/bit-babbler-sysctl.conf corekeeper: /etc/sysctl.d/corekeeper.conf dms-core: /etc/sysctl.d/30-dms-core-net.conf dms-core: /etc/sysctl.d/30-dms-core-shm.conf freedombox-setup: /etc/sysctl.d/freedombox.conf linux-grsec-base: /etc/sysctl.d/grsec.conf postgresql-common: /etc/sysctl.d/30-postgresql-shm.conf systemd: /etc/sysctl.d/99-sysctl.conf systemd-coredump: /usr/lib/sysctl.d/50-coredump.conf tracker-miner-fs: /etc/sysctl.d/30-tracker.conf uhd-host: /etc/sysctl.d/uhd-usrp2.conf > That makes it easy for the > sysadmin to override *either* by directly creating a file with the same > name in /etc *or* by adding a file later in the sequence to tweak > individual settings, both of which can easily be done in packages for > sysadmins who want to package their configuration tweaks. (By contrast, > a configuration package can't safely tweak or override existing files in > /etc, only drop in a file later in the sequence.) This also makes it > easy to use tools to identify any local overrides, or to just look in > /etc and see at a glance only what the sysadmin has modified, not large > swathes of stock values. > > Effectively, the bits installed in /usr/lib (or /lib) represent the > stock state of the package (similar to compiled-in defaults, but more > easily adjusted by the distribution without patching). > > This is something that people have argued over in the past, and will > likely continue to argue over; it's also highly correlated with general > argument over systemd, since systemd is the most popular package > following and encouraging this configuration pattern, though not the > first such package. However, this pattern is supported by upstream > convention, convention across multiple distributions (meeting sysadmin > expectations), and existing use by many other packages already in > Debian. Agreed. > > But this does not account for the fact that this specific tunable may be > > already overriden in another sysctl.d file and the package would reset > > it to a lower value? > > You might ask systemd upstream if they'd consider extending the syntax > to support "increase if below this value but don't decrease". But in > the absence of that, I don't think you need to worry about that kind of > configuration conflict unless it comes up. Ideally if multiple packages > need to change this limit, they'll coordinate and agree on the new > value, or perhaps even depend on a common configuration package. I think such an extension would be quite tricky and probably not worth it. Thanks Evgeni [1] https://patchwork.kernel.org/patch/9370199/
