On Sun, Apr 23, 2017 at 09:01:13PM +0200, Evgeni Golov wrote: > On Sun, Apr 23, 2017 at 11:40:34AM -0700, Josh Triplett wrote: > > On Sun, Apr 23, 2017 at 08:37:59PM +0200, Evgeni Golov wrote: > > > On Sun, Apr 23, 2017 at 10:48:33AM -0700, Josh Triplett wrote: > > > > Evgeni Golov wrote: > > > > > 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. > > > > Can't hurt to ask, given the use case. Doesn't seem like that much of a > > challenge to implement; the main challenge would be getting it > > propagated widely enough to use. > > That was my first thought, too. But then I realized you need operators for: > - increasing, like above > - decreasing like for vm.swappiness > - handling "booleans" and tri-states as used by several security features > granted, this is mostly as increasing
I think it'd suffice to add the one thing you currently want, and worry about other things in the future if they arise. Increasing works for a large number of cases.
