[systemd-devel] [PATCH] man: fix description of sysctl.d order

[Colin Guthrie]

'Twas brillig, and Kay Sievers at 12/09/13 00:22 did gyre and gimble:
> On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>> 'Twas brillig, and Mantas Mikulėnas at 11/09/13 22:53 did gyre and gimble:
>>> systemd-sysctl gives priority to the latest occurence as of commit
>>> 04bf3c1a60d82791e0320381e9268f727708f776, but the manpage hasn't been
>>> updated for that.
>>
>> Oh jeez... has the ordering flipped again??
>>
>> I only just rejigged things for the last time this flipped around and
>> now sysctl has decided to buck the trend of the other tools and follow a
>> "later file has priority"? I think consistency is good here (even if
>> conceptually, a later file overriding an earlier one "feels" better.
> 
> Yes, and later-override-earlier is by far the bigger trend. :)

I agree that I prefer it. It's just annoying that the sysctl stuff has
flipped and flipped back to this now after adjusting several tools and
such like to configure things and dealing with file renaming in %post
scripts etc. It's not nice to keep changing the behaviour like this :( I
hope this is now the final way of working and that Lennart also agrees
and that acks that his previous commit was the wrong approach.

>> The order was previously "fixed" such that earlier files win for several
>> tools binfmt, tmpfiles
> 
> These are multi-options lines which cannot really be merged or
> overwritten with multiple lines.
> 
> Avoiding conflicting entries seems the best approach here, and the
> first-one-wins, the later ones complain sounds like the best approach.

Hmmm, fair enough, but I don't see why these should be different to
sysctl.d here. Personally, (as you mentioned above) the
later-override-earlier to  me feels more natural, but I'll admit that I
don't fully grok how tmpfiles and binfmt should follow a first-one-wins
approach whereas sysctl.d should follow a later-override-earlier...

>> modules-load
> 
> This is just all loaded what's in there, no order, no overwrite, doesn't it?

Yeah this one is somewhat different I agree. I just copy pasted the
tools mentioned in Lennart's commit.

>> and sysctl in
>> fabe5c0e5fce730aa66e10a9c4f9fdd443d7aeda back in February.
> 
> Sysctl really should be able to handle, and always did in the past,
> conflicting entries, and we should not break that stuff. The old tool
> just wrote the values multiple times into the kernel.
> 
>> Is there a reason why sysctl.conf cannot just be symlinked as
>> sysctl.d/0-sysctl.conf rather than 99-sysctl.conf and keep the ordering
>> consistent with the other tools?
> 
> Where is that defined? /etc/sysctl.conf should not exist, in the ideal case.

I was just referring to your NEWS item message in
04bf3c1a60d82791e0320381e9268f727708f776 which Mantas referenced where
you said:

        * The systemd-sysctl tool does no longer natively read the
          file /etc/sysctl.conf. If desired, the file should be
          symlinked from /etc/sysctl.d/99-sysctl.conf. Apart from
          providing legacy support by a symlink rather than built-in
          code, it also makes the otherwise hidden order of application
          of the different files visible.

If it was symlinked from as 0-sysctl.conf and the ordering had remained
unchanged it would have achieved the same result no?


(side note: the version number in the changes is now duplicated - there
are two 206's. I guess the top one should be 207)


Col
-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/