|Summary:||sysctl.conf / sysctl.conf.d settings not read when modules are loaded|
|Product:||[Fedora] Fedora||Reporter:||Laine Stump <laine>|
|Component:||bridge-utils||Assignee:||David Woodhouse <dwmw2>|
|Status:||CLOSED EOL||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||22||CC:||amessina, arapov, artem.goncharov, awilliam, bburke264, brunojcm, crobinso, dcbw, djasa, djuran, dwmw2, edgar.hoch, gczarcinski, hancock, harald, herrold, hiroshi01.itani, jonathan, jwboyer, kmod-maint, lnykryn, m.koshelev, mschuppe, msivak, nfd, notting, pbrobinson, rc556677, rdieter, samuel-rhbugs, scott-fedora, sgraf, sjenning, twoerner, vpavlin, zbyszek|
|Fixed In Version:||initscripts-9.56.1-2.fc21||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||1122700 (view as bug list)||Environment:|
|Last Closed:||2016-07-19 20:50:20 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Laine Stump 2010-09-16 20:31:37 UTC
+++ This bug was initially created as a clone of Bug #634735 +++ Description of problem: On a system that has no bridges defined in /etc/sysconfig/network-scripts/ifcfg-*, but does have virtual networks defined in libvirtd, when system boot is complete the setting of net.bridge.bridge-nf-call-iptables is always "1", regardless of what is set in /etc/sysctl.conf. Version-Release number of selected component (if applicable): bridge-utils-=1.2-9.fc13.x86_64 How reproducible: 100% Steps to Reproduce: 1. install a new system with the Virtualization package included. (or just make sure that your current system has no bridges defined in /etc/sysconfig/network-scripts, and does have at least one virtual network defined in libvirt (the basic libvirt install has a virtual network, "default", defined) 2. Make sure that /etc/sysctl.conf contains: net.bridge.bridge-nf-call-iptables = 0 (this is the default on a new install). 3. After the system has completed booting, run: sysctl net.bridge.bridge-nf-call-iptables Actual results: net.bridge.bridge-nf-call-iptables = 1 Expected results: net.bridge.bridge-nf-call-iptables = 0 Additional info: Bug 629206 and Bug 633346 suffer some of the blow-by from this - although their root cause is different, the obvious workaround (setting net.bridge.bridge-nf-call-iptables = 0) doesn't always work, because that setting doesn't always make it into the kernel. Another related item is given in the description of a patch to the netcf library: https://fedorahosted.org/pipermail/netcf-devel/2010-September/000459.html The cause of the problem is: 1) Before the bridge module is loaded, those variables don't yet exist, so any sysctl.conf reload has no effect on them 2) The network service reloads /etc/sysctl.conf, and happens to do that after it has caused the bridge module to load, but it only loads the bridge module if there are bridge interfaces to ifup. 3) the default for this setting (as well as *-ip6tables and *-arptables) in the bridge module is 1 4) no other init script happens to reload sysctl.conf after the network service. 5) if libvirt has any virtual networks, those require a bridge interface to be created, and one of the involved commands (brctl?) causes the bridge module to be loaded, but doesn't reload sysctl.conf, so we're left with the module's default (1) rather than the configured default in sysctl.conf. I *think* the fix is that either the initialization of the bridge module itself, or whatever utility does the modprobe of the bridge module, needs to run "sysctl -a -p" to cause the configured defaults to be loaded as soon as possible after the bridge module is loaded. It's not correct to rely on someone else (eg, the network service) to know that this must be done.
Comment 1 Bug Zapper 2011-05-31 13:18:26 UTC
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Fedora End Of Life 2013-04-03 18:33:07 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 3 Edgar Hoch 2013-08-28 22:43:49 UTC
This problem still exists in Fedora 19. /usr/lib/sysctl.d/00-system.conf contains the lines net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0 but when this seems to be ignored: # sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-iptables = 1 After explicit loading the values with # sysctl --system then the parameters have the correct values: # sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-iptables = 0 Is there a solution to solve this? It seems that the sysctl parameters was loaded at startup: # systemctl status systemd-sysctl.service systemd-sysctl.service - Apply Kernel Variables Loaded: loaded (/usr/lib/systemd/system/systemd-sysctl.service; static) Active: active (exited) since Do 2013-08-29 00:24:21 CEST; 11min ago Docs: man:systemd-sysctl.service(8) man:sysctl.d(5) Process: 584 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=0/SUCCESS) But as earler comments explain, it seems that the kernel module bridge is loaded after executing systemd-sysctl.service, and sysctl is not reexecuted after loading that kernel module. For using virtual machines it is neccessary to either disable the use of the iptables (using this kernel parameters) or to change the iptables configuration with a line like this: iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT But this iptables command is not compatible with firewalld in Fedora 19, we cannot enter it in firewalld and firewalld cannot save this permanently. The old way to save iptable rules is not compatible with firewalld.
Comment 4 Edgar Hoch 2013-08-28 23:01:07 UTC
I found that for network.service the file /etc/rc.d/init.d/network contains two calls to apply_sysctl in the start part of the script. apply_sysctl is a shell functions and calls /lib/systemd/systemd-sysctl . So using network.service would probably reload the sysctl parameters after starting the network devices. But I use NetworkManager - I think NetworkManager.service is preferred by the Fedora designers over network.service (is it right?). It seems that NetworkManager doesn't reload the sysctl parameters after activating the network devices (or at least the first time, when kernel modules are loaded for a device).
Comment 5 Edgar Hoch 2013-08-29 02:55:27 UTC
Created attachment 791572 [details] /etc/NetworkManager/dispatcher.d/00-0sysctl I have created a dispatcher file for NetworkManager that reloads the kernel parameter after change of a network interface. I have installed this file as /etc/NetworkManager/dispatcher.d/00-0sysctl (mode 0755) After reboot the kernel parameter are as expected: # sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-iptables = 0
Comment 6 Robert Hancock 2014-01-18 00:27:04 UTC
This problem still exists in Fedora 20. A KVM bridged guest cannot get proper network access without some manual intervention to cause these sysctl parameters to be set.
Comment 7 Edgar Hoch 2014-01-25 00:28:22 UTC
I think that until a better solution is implemented a script like that of comment #5 should be included in package NetworkManager (for F19, F20, Rawhide). I think this would be better than doing nothing for years. Pro: sysctl kernel values defined in the sysctl config files will be loaded. Con: sysctl kernel values changed by hand may be overwritten by the values defined in the sysctl config files. Perhaps this bug need to be cloned for component NetworkManager for implementing the workacround from comment #5 ? A real solution - the best? - should be that every kernel module will check for parameters in sysctl config files immediate after loading the kernel module. This would avoid the con listed above.
Comment 8 Laine Stump 2014-01-28 13:38:22 UTC
That script only solves the problem if the NetworkManager service is running, *and* there is a change to an interface which NetworkManager knows about / has control over. Dynamically created transient bridge device are not controlled by NetworkManager (for that matter NetworkManager may not even be running - there are still a lot of people that use the old "network" service). For that reason, I would be concerned that putting a workaround in NetworkManager may only server to make the origins of the problem less obvious, since settings would sometimes be correct and sometimes not. BTW, this really is a general problem with all kernel tunables, so I don't know that it's even appropriate leaving it assigned to bridge-utils. I'm not sure where to re-assign it that it would just be closed out-of-hand though...
Comment 9 Edgar Hoch 2014-01-28 14:11:01 UTC
I agree that this is a general problem and bridge-utils is not the right component to solve the general problem. I think we need a temporary short-term solution that is not perfect but works for some or better most users - let it call workaround. And we need a long-term solution for the general problem. Yes, it's true, my script does not work for the old network service. Do you know a (another) workaround for the old network service? I think there should be a new (or cloned) bug report which describes the general problem. It could be assigned to kernel? For solving the general problem, I have the following idea: - The kernel should remember parameters set by sysctl even if this parameter does not exist in the kernel at the time when the parameter was set. When the parameter is created later (for example by loading a module), the kernel should check the list of previous loaded parameters and if the parameter is found, this value should be used as default instead of other defaults. This solution needs changes in the kernel. But it sets the values at the right time (only the kernel knows when a parameter is created) and it has less overhead than other solutions (for example like checking sysctl config files after every module load).
Comment 10 Robert Hancock 2014-01-28 15:54:07 UTC
As far as I can tell, all of the other default sysctl settings provided in Fedora seem to be for built-in components of the kernel so this problem doesn't present itself for them. I suppose one solution to this would be to just build the bridge module into the kernel so that we don't have the issue of the module not being loaded when the settings are applied. The only downside would be some amount of kernel size overhead for people that didn't need bridge functionality. I wonder how other distros are handling this?
Comment 11 Laine Stump 2014-01-29 11:42:21 UTC
(In reply to Robert Hancock from comment #10) > I suppose one solution to this would be to > just build the bridge module into the kernel so that we don't have the issue > of the module not being loaded when the settings are applied. An interesting suggestion that at least solves the problem for all usages of bridge module tunables anyway. What do the bridge-utils maintainers think of this?
Comment 12 Richard Chan 2014-03-21 15:52:43 UTC
A horrible work-around would be to force early load /etc/modules-load.d/10-bridge.conf: # load bridge module # sysctl problem bridge # sysctl -a | grep table net.bridge.bridge-nf-call-arptables = 0 net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 ...but it's not clear who should be responsible for installing this file maybe bridge-utils?
Comment 13 David Woodhouse 2014-04-28 09:29:01 UTC
(In reply to Edgar Hoch from comment #7) > A real solution - the best? - should be that every kernel module will check > for parameters in sysctl config files immediate after loading the kernel > module. You could probably do this with a fairly simple hotplug invocation. Just tell userspace that the new sysctl table came into existence, and let it handle things accordingly. Not sure how that interacts with network namespaces though. I have no fundamental objection to loading the bridge module into the kernel either, except that it's a dirty hack to solve it for just this case. You'd want to talk to the kernel maintainers about that.
Comment 14 Anton Arapov 2014-07-16 08:45:50 UTC
Experiencing same issue in CentOS7. Bug 1054178 is the dupe.
Comment 15 Adam Williamson 2014-07-23 17:57:57 UTC
I'm seeing this too. It doesn't just apply to cases where there's no bridges in /etc/sysconfig/network-scripts , I think it applies to any case where you use NetworkManager not network.service (so you don't get the workaround noted in c#4). I just tried setting up bridged networking with libvirt/NetworkManager on a Fedora 21 box to see how good/bad it is these days, and this is one of several issues I ran into. It's very non-obvious, I only figured it out with the help of an ancient Fedora 13 doc. CCing dcbw for the NetworkManager take and jwb for the kernel take; how should we fix this properly?
Comment 16 Adam Williamson 2014-07-23 18:26:04 UTC
so, I think Edgar's 'real solution' from c#8 is the best fix here, and jforbes thinks it makes sense: <adamw> i.e. sysctl settings should be read when kernel modules are loaded <jforbes> adamw: yes, that would make sense <adamw> jforbes: is it practical to implement? <jforbes> adamw: I don't think it would be that difficult, though it would have to be done in kmod so, assigning this to kmod to see if it'll get some traction there. I'm willing to bet a couple of beers that some RHEL 7 users will run across this trying to use libvirt bridging with NetworkManager, if that provides any incentive to bump up its importance...
Comment 17 Adam Williamson 2014-07-23 18:31:22 UTC
*** Bug 1054178 has been marked as a duplicate of this bug. ***
Comment 18 Adam Williamson 2014-07-23 18:34:08 UTC
Hrm. In a RHEL report on the same bug, Bill Nottingham noted: "- 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)." which sounds like systemd should be taking care of this, but it doesn't seem to be. CCing Bill: can you elaborate? Should systemd know to apply these settings when the 'bridge' module is loaded? Is there a bug in systemd?
Comment 19 Adam Williamson 2014-07-23 18:49:14 UTC
sysctl.d manpage notes: "Many sysctl parameters only become available when certain kernel modules are loaded. Modules are usually loaded on demand, e.g. when certain hardware is plugged in or network brought up. This means that systemd-sysctl.service(8) which runs during early boot will not configure such parameters if they become available after it has run. To set such parameters, it is recommended to add an udev(7) rule to set those parameters when they become available." The example udev rule given for bridging is: /etc/udev/rules.d/99-bridge.conf: ACTION=="add", SUBSYSTEM=="module", KERNEL=="bridge", RUN+="/usr/lib/systemd/systemd-sysctl --prefix=/proc/sys/net/bridge" so...possibly we should be shipping such a udev rule ourselves. Let's bring in the systemd folks, why not, everyone else is at the party already...
Comment 20 Bill Nottingham 2014-07-24 14:06:12 UTC
systemd automatically reapplies for anything loaded by systemd-modules-load.service; it also has: # Apply sysctl variables to network devices (and only to those) as they appear. ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", RUN+="/usr/lib/systemd/systemd-sysctl --prefix=/proc/sys/net/ipv4/conf/$name --prefix=/proc/sys/net/ipv4/neigh/$name --prefix=/proc/sys/net/ipv6/conf/$name --prefix=/proc/sys/net/ipv6/neigh/$name" for network devices. It doesn't handle any cases outside of that. Arguably, I could see modules registering their sysctl range somehow so you could just do: ACTION=="add", SUBSYSTEM=="module", RUN+="/usr/lib/systemd/systemd-sysctl --prefix=/proc/sys/$kernel" (replace $kernel with whatever the variable is) But that requires kernel changes.
Comment 21 Harald Hoyer 2014-08-20 15:03:31 UTC
I would go with: SYSCTL#1: create a udev rule ACTION=="add", SUBSYSTEM=="module", KERNEL=="bridge", RUN+="/usr/lib/systemd/systemd-sysctl --prefix=/proc/sys/net/bridge" as a short term solution. Long term, we should probably add a modinfo alias like we did for devname. # modinfo loop filename: /lib/modules/3.16.0-1.fc22.x86_64/kernel/drivers/block/loop.ko.xz alias: devname:loop-control alias: char-major-10-237 alias: block-major-7-* .... So, I could imagine: alias: sysctl:/proc/sys/net/bridge
Comment 22 Gene Czarcinski 2014-08-28 18:55:24 UTC
Using Adam's writeup: https://www.happyassassin.net/2014/07/23/bridged-networking-for-libvirt-with-networkmanager-2014-fedora-21/ which uses the udev-rule to set again the kernel parameters work well. I now have brided networks for qemu-kvm virtual systems. However, for secure (lxc) containers (virt-sandbox-service), I needed to define a virtual network of the form: <network> <name>net18</name> <uuid>8d19a05b-ac85-4e2a-88bc-5ca4cbb29a33</uuid> <forward mode='bridge'/> <bridge name='br0'/> </network> This "net18" could be used with virtual systems or secure containers. Unfortunately, dhcp does not work but that is OK for my purposes since I need to use a static IP (BZ #1133686). What I find a little stange is that this bug has existed for so long a time. Thanks go to Adam for pushing something that works.
Comment 23 Fredy Neeser 2014-09-02 19:09:25 UTC
(In reply to Adam Williamson (Red Hat) from comment #19) Many thanks to Adam for his writeup (see link in comment #22)! The udev rule worked for me, too (on a Fedora 20 I had just upgraded from 19), after noting the error in the sysctl.d manpage: > sysctl.d manpage notes: > > "Many sysctl parameters only become available when certain kernel modules > are loaded. Modules are usually loaded on demand, e.g. when certain hardware > is plugged in or network brought up. This means that > systemd-sysctl.service(8) which runs during early boot will not configure > such parameters if they become available after it has run. To set such > parameters, it is recommended to add an udev(7) rule to set those parameters > when they become available." > > The example udev rule given for bridging is: > > /etc/udev/rules.d/99-bridge.conf: ^ | This should be 99-bridge.rules > ACTION=="add", SUBSYSTEM=="module", KERNEL=="bridge", > RUN+="/usr/lib/systemd/systemd-sysctl --prefix=/proc/sys/net/bridge" Of course, udev will ignore a udev rules file that doesn't have a .rules extension ... Should we open a bug against the sysctl.d manpage? (see Example 2, /etc/udev/rules.d/99-bridge.conf)
Comment 24 Zbigniew Jędrzejewski-Szmek 2014-09-02 23:38:07 UTC
(In reply to Fredy Neeser from comment #23) > Should we open a bug against the sysctl.d manpage? > (see Example 2, /etc/udev/rules.d/99-bridge.conf) No need, fixed in http://cgit.freedesktop.org/systemd/systemd/commit/?id=a7a0912a36. Thanks for the report.
Comment 25 Gene Czarcinski 2014-10-04 16:50:04 UTC
I spoke too soon. The "99-bridge,rules" solution does not always work. Works fine on "fast" systems (i7-4770) but not on "slow" systems (i5-4570 + SSD and slower).
Comment 26 Gene Czarcinski 2014-10-04 16:59:55 UTC
Claqrification: The hosts bridged interfaces work just fine. However, virtual interfaces such as those used by Secure Containers or libvirt/qemu/kvm virtual systems do not.
Comment 27 Gene Czarcinski 2014-10-05 10:59:58 UTC
This is a hack but I do not consider it horrable at all. One of the previous comments suggest that incorporating the bridge module directly into the kernel was an acceptable fix. Therefore, doing warly loading of the bridge module should also be acceptable. While waiting for the final perfect answer, simply adding a file with bridge in /etc/modules-load.d/ should also be acceptable. Tested and it works on all of my systems and on Fedora 20 as well as Fedora 21. My testing on Fedora 21 is somewhat limited because other errors involving libvirt-sandbox and virt-sandbox-service Secure Containers. See RHBZS #1135762 While I believe that there is some sort of race condition which is forcing the early load, it is not clear to me what it is. On the works without early load, I have a i7-4770 and an AMD 8150 Eight core processor with the systems on SSDs and /boot on rotating rust. On the works only with early load, I have SSD-only systems with i5-4570 and Intel Atom D2500 @ 1.86GHz processors.
Comment 28 Fedora Update System 2014-10-10 21:24:01 UTC
initscripts-9.56.1-1.fc21, systemd-216-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/initscripts-9.56.1-1.fc21,systemd-216-3.fc21
Comment 29 Fedora Update System 2014-10-12 05:05:17 UTC
Package initscripts-9.56.1-1.fc21, systemd-216-3.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing initscripts-9.56.1-1.fc21 systemd-216-3.fc21' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-12688/initscripts-9.56.1-1.fc21,systemd-216-3.fc21 then log in and leave karma (feedback).
Comment 30 Fedora Update System 2014-10-14 04:33:50 UTC
Package systemd-216-4.fc21, initscripts-9.56.1-2.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-216-4.fc21 initscripts-9.56.1-2.fc21' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-12688/initscripts-9.56.1-2.fc21,systemd-216-4.fc21 then log in and leave karma (feedback).
Comment 31 Cole Robinson 2014-10-14 08:31:46 UTC
FWIW the systemd build only contains the man page fix and doesn't actually fix the root issue.
Comment 32 Zbigniew Jędrzejewski-Szmek 2014-10-14 12:17:53 UTC
Pfff, you had me doubting for a moment here. But no, everything seems to be in order. $ rpm -ql systemd|grep bridge /usr/bin/systemd-stdio-bridge /usr/lib/sysctl.d/50-bridge.conf /usr/lib/udev/rules.d/99-bridge.rules $ rpm -q systemd systemd-216-4.fc21.x86_64
Comment 33 Cole Robinson 2014-10-15 07:57:21 UTC
Zbigniew, sorry, this bug has a lot going on, and maybe I missed something. Kinda confusing since this is filed against kmod, and the only reference to this bug number in systemd git is the man page fix...
Comment 34 Zbigniew Jędrzejewski-Szmek 2014-10-15 12:11:30 UTC
(In reply to Cole Robinson from comment #33) > Zbigniew, sorry, this bug has a lot going on, and maybe I missed something. > Kinda confusing since this is filed against kmod, and the only reference to > this bug number in systemd git is the man page fix... That is possible. So the situation looks like this: Solution from comment #20 is implemented (i.e. also the solution that I added to the man page) as a non-upstream patch in systemd.rpm, which adds special udev rules and a sysctl file for bridge settings. The more general and less hacky solution from comment #21 is unfortunately not implemented, but I'd love for it to happen.
Comment 35 Laine Stump 2014-10-15 12:58:13 UTC
Yay! I just tested this in an F21 vm which has no bridges in the system network config, but does have a bridge created at a later time by libvirt - prior to updating, these were the values of the bridge-nf-call-* tunables (in spite of being set to 0 in /usr/lib/sysctl.d): net.bridge.bridge-nf-call-arptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 But after updating (and with no other modifications), I rebooted the vm and found this: net.bridge.bridge-nf-call-arptables = 0 net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 So the changes you made *did* fix the original bug that I filed the BZ over - thanks! Will this BZ be moved from MODIFIED to CLOSED automatically when the relevant packages make it into f21-updates, or does it need to be in ON_QA for that to happen?
Comment 36 Cole Robinson 2014-10-15 13:39:04 UTC
> > Will this BZ be moved from MODIFIED to CLOSED automatically when the > relevant packages make it into f21-updates, or does it need to be in ON_QA > for that to happen? yes, the fedora updates system will close this bug when systemd hits f21 stable repo
Comment 37 Fedora Update System 2014-10-21 17:24:54 UTC
Package initscripts-9.56.1-2.fc21, systemd-216-5.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing initscripts-9.56.1-2.fc21 systemd-216-5.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-12688/initscripts-9.56.1-2.fc21,systemd-216-5.fc21 then log in and leave karma (feedback).
Comment 38 Fedora Update System 2014-10-28 21:49:15 UTC
initscripts-9.56.1-2.fc21, systemd-216-5.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Comment 39 Lennart Poettering 2015-02-16 17:02:30 UTC
Hmm, I really disagree with this fix. I am absolutely sure we shouldn't add similar rules for any kmod that comes along. People really should find a different way for this: write their own udev rules or whatever they like, but doing this for ever single kmod in systemd is not an option. I will now remove this patch from f22. This really has no place in the systemd RPM. If you really want to keep this, move it to the bridge-utils or so, but honestly: it's really time to forget sysctls for modules, it will not work, and people shouldn't try.
Comment 40 Lennart Poettering 2015-02-16 17:10:31 UTC
To summarize my stance on this: - doesn't belong in systemd.rpm, if at all it should be in bridge-utils or so - really bad idea in general, you cannot win, there are so many kmods, so it should not happen at all. And even if you added this for every single kmod that exports a sysctl, you'd slow down the boot tremendously, since sysctl needs to be forked off for every single one of them. - fedora-specific "solutions" to this are a bad idea anyway, let's make everybody use the same logic here, and that should be udev rules.
Comment 41 Cole Robinson 2015-02-16 17:45:11 UTC
Reopening for f22 and reassigning to bridge-utils per comment #40
Comment 42 Edgar Hoch 2015-02-16 21:40:42 UTC
I agree that forking "sysctl" for each loaded module induce much unnecessary overhead. So we need a better solution. I think it may be too complicated for an ordinary user - and for an ordinary administrator too - to write udev rules when he just want to change the value of a parameter. udev rules are much more complex than a single parameter assignment. I think that there should be a tool with a simple user interface like sysctl, which users and admins can use to read, set and change parameters of the system. It may generate udev rule files instead of sysctl config files, that would be ok. It should have at least a cli, but some gui (maybe combined with other configuration tools) would be nice too. The tool should support temporary changes of the parameters (to the running system, lost after reboot) and permanant changes (changes files in /etc/...) - preferred by the same tool. There should also be some reasonable defaults for frequent use cases. I think bridges with a vm (kvm, libvirt) with external ip addresses (not nat) is a typical case. virsh is no help for this case (see bug #1134569).
Comment 43 Scott Shambarger 2015-02-22 19:31:40 UTC
Just noticed the boot message: bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. The new module appears to export the bridge sysctl values, but the udev rule in /lib/udev/rules.d/99-bridge.rules still refers to the bridge module (not the br_netfilter module), and so the bridge netfilter values after loading br_netfilter are: net.bridge.bridge-nf-call-arptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 Granted, if you load br_netfilter explicitly, you probably want to use it, but then /usr/sysctl.d/50-bridge.conf should probably be removed as it is no longer needed to disable bridge netfilter (by default) anymore.
Comment 44 Laine Stump 2015-02-23 19:45:28 UTC
After all these years of asking for the default of bridge filtering to be "disabled" and the change being refused by the kernel maintainers, now the filtering has been moved into a separate module that isn't loaded (by default) when the bridge module is loaded, effectively making the default "disabled". Yay! I *think* this is in the kernel as of 3.17 (It definitely is in kernel 3.18.7-200.fc21, and appears to be in git prior to the tag "v3.17-rc4") So again the problem has disappeared for our case, so we're happy, but the general problem (as in the latest version of this bug's summary) is still there. What is the proper action for this BZ then? Do we leave it around (knowing that, based on the experience up to now, the general problem will likely never be fixed), close it as WONTFIX, or close it with one or another of the "resolved" reasons, since our particular problem has been fixed by the addition of the new module?
Comment 45 Fedora End Of Life 2016-07-19 20:50:20 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.