Description of problem: sysctl -p on a fresh install of F13 gives: error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key error: "net.bridge.bridge-nf-call-iptables" is an unknown key error: "net.bridge.bridge-nf-call-arptables" is an unknown key Version-Release number of selected component (if applicable): initscripts-9.12.1-1.fc13.i686 kernel-PAE-2.6.34.7-56.fc13.i686 How reproducible: Allways Steps to Reproduce: 1. Install system 2. Do "sysctl -p" 3. Actual results: error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key error: "net.bridge.bridge-nf-call-iptables" is an unknown key error: "net.bridge.bridge-nf-call-arptables" is an unknown key Expected results: No errors in output. Additional info:
Correct; pass '-e' if you want to avoid this.
Why are those unknown keys in there?
They are automatically applied for use with virtualized networking. (They end up being applied via later calls post-boot.)
(In reply to comment #1) > Correct; pass '-e' if you want to avoid this. I fail to see how this is not a bug as it breaks some of our automated scripts that care about the exit status of the sysctl command. We did not have this problem on el5 but it now manifests on el6. Wouldn't it be better if these keys were added by the particular virtualization package that needs them?
I agree 100% with Benjamin. This is causing errors with our configuration management system (puppet), and it's not as simple there to just pass "-e", nor is it the right thing to do.
I'm having the same problem. This is most certainly a bug. Please reopen and fix.
Tim, J - what releases are you seeing this on, because the implementation has changed somewhat recently. (I'm assuming Fedora, given the bug. If you're seeing something in RHEL, that needs reported as RHEL, because that has different parameters for when & how things get fixed, obviously...) This change was added per request in mid-2009, via bug 512206. At that time: - we only had support for a single sysctl.conf, rather than sysctl.d drop-in directories - we had no mechanism for triggering specific sysctls on module load/initialization (other than complex udev rules) Now, we've got a lot more features we can use here: - we have support for /etc/sysctl.d and /usr/lib/sysctl.d, for service-provided drop-in directories, with a defined hierarchy of overrides. (See 'man sysctl.d'). - we have systemd support for applying keys on module load (in fact, systemd is what applies keys at boot time now, rather than a script) So, starting in F-18, all the system defaults (such as this) have moved to /usr/lib/sysctl.d/00-system.conf, which is read by systemd and applied at boot (or after any necessary modules have loaded). Admins can still customize and change any configurations they need in /etc/sysctl.conf, or /etc/sysctl.d/<whatever>.conf, and they will override these settings. Plus, running 'systctl -p /etc/sysctl.conf' will now no longer throw errors such as this, because the system default keys (as opposed to the administrator-changed keys) are applied differently. So your config system should now work better in this case. Because of that, flipping this from CLOSED->NOTABUG to CLOSED->CURRENTRELEASE, as it *should* be fixed for you in F-18.
I didn't notice when I commented on this that this bug was specific to Fedora. We're seeing this in RHEL, and that's really where I care about seeing it fixed.
Tim - OK, I've cloned this bug for RHEL (919472) - might be worth prodding your support rep to escalate the issue there.