On Wed, Dec 14, 2011 at 1:23 AM, C Anthony Risinger <[email protected]> wrote: > On Tue, Dec 13, 2011 at 2:44 PM, lolilolicon <[email protected]> wrote: >> On Wed, Dec 14, 2011 at 3:48 AM, Tom Gundersen <[email protected]> wrote: >>> On Tue, Dec 13, 2011 at 8:09 PM, lolilolicon <[email protected]> wrote: >>>> >>>> According to sysctl(8), the -e option is used to "ignore errors about >>>> unknown keys", so no "other error" would be hidden by it. >>> >>> Many reasons for "unknown keys", maybe the module is no longer >>> installed (by mistake), or it failed loading, or, .... >> >> But in case of those failures, one shouldn't expect to look for errors in >> the sysctl error messages in the first place. Those error messages should >> be supplementary at best. >> >>> >>>> It's a good thing if we can report error on misspelled keys, but only if >>>> we don't report the same errors when the keys are just unknown due to >>>> disabled modules. >>> >>> I can't imagine how that could be done... >>> >>>> Currently I have IPv6 disabled, so I get in boot >>>> messages: >>>> >>>> error: "net.ipv6.conf.all.use_tempaddr" is an unknown key >>>> error: "net.ipv6.conf.default.use_tempaddr" is an unknown key >>> >>> To me it makes most sense to disable the sysctl entries if you disable >>> the modules, anything else should give errors. >> >> To me, the sysctl entries are to the modules what configuration files are >> to e.g. daemons -- you don't comment/rename configs if you disable daemons >> in rc.conf. >> >>> >>>> Now if I consistently get these errors, it would be very likely for me to >>>> ignore some other real errors, like misspelling: >>>> >>>> error: "net.ipv9.conf.default.use_tempaddr" is an unknown key >>> >>> With your patch this error would be ignored anyway... >> >> Yes, but if in either case it will be ignored, better just not print it :P >> My point is that if one gets used to the net.ipv6.* key errors, other real >> errors would more likely be ignored; if instead, we suppress the >> non-critical unknown key errors, the other real errors will stand out. >> >>> >>>> BTW, pre arch-sysctl, it used to be `sysctl -q -p &>/dev/null`, which >>>> really hides *all* errors; >>> >>> Yeah, we are slowly moving away from ignoring errors wherever we can. >> >> I can understand the intent. >> >>> >>>> in contrast, The -e option sounds far more >>>> reasonable... >>> >>> Sure, but it still risks ignoring some real errors, which is worse >>> than being annoying. >> >> I still think in reality -e is pretty safe; I wonder what the original >> intent for the -e option. >> >> Well, I think I've made my points. Comparing options, I would add the -e >> to my copy of arch-sysctl, if unfortunately we couldn't agree on this >> matter. > > i don't know how beneficial it is to worry about disabled daemons, or > much else related to sysctl ... because imo the whole thing is > busted/outdated, even sysctl.d as implemented by systemd. in > `/etc/rc.multi`, `arch-sysctl` is called *before* any daemons are > started, so anything added to /proc after that will not be affected > anyway (eg. any modules loaded by daemons et al). > > the sad truth is sysctl is not hot-plug friendly at all AFAIK, and > only sysfs attributes (/sys) can be [cleanly] modified by udev rules > ... > > i know this because i have a desire to disable bridge firewalling on > many of my setups, a /proc/net entry, but the hierarchy doesn't exist > until the bridge modules are loaded ... which, unless explicitly > requested, will almost certainly happen after sysctl stuff has fired.
Yes, sysctl loading is not hotplug ready... I am rather in the opinion of Tom, we do not have to hide errors. Maybe your patch would be more friendly if you check if quiet parameter is given during boot? -- Sébastien Luttringer www.seblu.net
