Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order
On Thu, Sep 12, 2013 at 9:49 AM, Colin Guthrie wrote: >> 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... See the later mail, binfmt is doing the opposite of what the man page said, tmpfiles requires uniqueness, everything else is an error. >>> 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? Yes, you can now control the policy with the file name instead of built-in logic. Fedora will use 99- to let the "admin's local machine config" which is usually empty always win. > (side note: the version number in the changes is now duplicated - there > are two 206's. I guess the top one should be 207) That's intentional, distcheck will not work with NEWS and configure.ac in sync. We can change that only directly before release. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order
'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 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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order
On Thu, Sep 12, 2013 at 4:49 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Sep 12, 2013 at 04:14:24AM +0200, Kay Sievers wrote: >> On Thu, Sep 12, 2013 at 1:22 AM, Kay Sievers wrote: >> > On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie >> > wrote: >> >> >> 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. :) >> > >> >> The order was previously "fixed" such that earlier files win for several >> >> tools binfmt, tmpfiles >> >> modules-load >> >> Oh, what a mess. Quite a few man pages described pretty much the >> opposite of what is done, not only in that file this patch fixed. >> >> I now hopefully fixed all of the man pages to describe what the code >> does. Now we have: >> >> binfmt - the last entry wins, people are allowed to overwrite earlier stuff >> tmpfiles - the first entry wins; uniqueness required, everything else an >> error >> sysctl - the last entry wins, people are allowed overwrite earlier stuff >> presets - the first entry wins, the search just stops there >> modules-load - there is no order, it's just a set of names that gets >> applied > Hm, and .service and service.d/*.conf? I think last entry wins also. Right, that's also assignment-style, allows overwriting, like sysctl or shell variable, and the last one wins. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order
On Thu, Sep 12, 2013 at 04:14:24AM +0200, Kay Sievers wrote: > On Thu, Sep 12, 2013 at 1:22 AM, Kay Sievers wrote: > > On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie > > wrote: > > >> 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. :) > > > >> The order was previously "fixed" such that earlier files win for several > >> tools binfmt, tmpfiles > >> modules-load > > Oh, what a mess. Quite a few man pages described pretty much the > opposite of what is done, not only in that file this patch fixed. > > I now hopefully fixed all of the man pages to describe what the code > does. Now we have: > > binfmt - the last entry wins, people are allowed to overwrite earlier stuff > tmpfiles - the first entry wins; uniqueness required, everything else an > error > sysctl - the last entry wins, people are allowed overwrite earlier stuff > presets - the first entry wins, the search just stops there > modules-load - there is no order, it's just a set of names that gets applied Hm, and .service and service.d/*.conf? I think last entry wins also. > There is no strictly consistent behavior between the different tools, > and I think for good reason, the do different things, some assign > values, some can't merge entries and require uniqueness, soem are just > lists; all seem to have their reason to do it in the way that makes > the most sense. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order
On Thu, Sep 12, 2013 at 1:22 AM, Kay Sievers wrote: > On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie wrote: >> 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. :) > >> The order was previously "fixed" such that earlier files win for several >> tools binfmt, tmpfiles >> modules-load Oh, what a mess. Quite a few man pages described pretty much the opposite of what is done, not only in that file this patch fixed. I now hopefully fixed all of the man pages to describe what the code does. Now we have: binfmt - the last entry wins, people are allowed to overwrite earlier stuff tmpfiles - the first entry wins; uniqueness required, everything else an error sysctl - the last entry wins, people are allowed overwrite earlier stuff presets - the first entry wins, the search just stops there modules-load - there is no order, it's just a set of names that gets applied There is no strictly consistent behavior between the different tools, and I think for good reason, the do different things, some assign values, some can't merge entries and require uniqueness, soem are just lists; all seem to have their reason to do it in the way that makes the most sense. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order
On Thu, Sep 12, 2013 at 01:22:20AM +0200, Kay Sievers wrote: > On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie 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. Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order
On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie 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. :) > 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. > modules-load This is just all loaded what's in there, no order, no overwrite, doesn't it? > 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. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order
'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. The order was previously "fixed" such that earlier files win for several tools binfmt, tmpfiles, modules-load and sysctl in fabe5c0e5fce730aa66e10a9c4f9fdd443d7aeda back in February. 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? 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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: fix description of sysctl.d order
systemd-sysctl gives priority to the latest occurence as of commit 04bf3c1a60d82791e0320381e9268f727708f776, but the manpage hasn't been updated for that. --- man/sysctl.d.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/sysctl.d.xml b/man/sysctl.d.xml index 69e96ee..ce5c34f 100644 --- a/man/sysctl.d.xml +++ b/man/sysctl.d.xml @@ -92,7 +92,7 @@ alphabetical order, regardless in which of the directories they reside, to guarantee that a specific configuration file takes precedence over another file -with an alphabetically later name, if both files +with an alphabetically earlier name, if both files contain the same variable setting. If the administrator wants to disable a -- 1.8.4.242.gbb80ee0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
