Red Hat Bugzilla – Bug 313051
iptables modules fail to unload
Last modified: 2008-06-17 08:55:02 EDT
Description of problem: Stop or restart of iptables causes error message : unloading iptables modules FAILED. Version-Release number of selected component (if applicable): Linux 2.6.22.9-91 with iptables 1.3.8-2.1.fc7. Happened with Linux 2.6.22.5-76 too. How reproducible: Happens every time iptables stopped Steps to Reproduce: 1. as root exec /etc/init.d/iptables stop OR stop or restart iptables from services 2. 3. Actual results: Failed message Expected results: OK message Additional info: None
Just seen this reported for CentOS too.
Please attach the output of "sh -x /etc/init.d/iptables stop".
Created attachment 212171 [details] output from sh -x /etc/init.d/iptables stop
Created attachment 212181 [details] 2nd log 2> 2nd log
Can you please make a "sh -x /etc/init.d/iptables stop 2>&1" after starting the firewall.
Created attachment 212651 [details] sh -X of /etc/init.d/iptables stop after a start
Created attachment 212661 [details] message log of entries from iptables
Additional. After a stop of the firewall it is now not possible to restart it. I have to reboot. Second. I see this same problem with a FC6 server too as of this evening. Thanks
According to comment #7 there are unknown symbols in the netfilter modules. This is not an iptables problem. Assigning to kernel.
It seems nf_conntrack_ipv4 isn't getting unloaded. Is it still loaded after the script fails?
No. It is loaded initially but gets unloaded when iptables stops. It is not loaded after the firewall is started again - along with other iptables modules that fail. A reboot is needed to the firewall working again. The attachment is taken from a FC6 server which is acting in the same way as the F7 one - I cannot mess with F7 right now. The results are the same though because I looked before.
Created attachment 214161 [details] lsmod output for firewall stop and start
Comment on attachment 214161 [details] lsmod output for firewall stop and start This is FC6 by the way. FC6 is doing exactly what F7 is doing but I cannot stop and restart f7 right now.
Are there any error messages in the kernel log when it fails to restart?
(In reply to comment #14) > Are there any error messages in the kernel log when it fails to restart? The only kernel originated messages have been provided as per comment 7.
These are the latest messages from the message log from the kernel after s atop and start of the firewall. Oct 6 13:09:06 pluto kernel: Removing netfilter NETLINK layer. Oct 6 13:09:06 pluto kernel: Netfilter messages via NETLINK v0.30. Oct 6 13:09:06 pluto kernel: nf_conntrack version 0.5.0 (8192 buckets, 65536 max) Oct 6 13:09:06 pluto kernel: ip_tables: (C) 2000-2006 Netfilter Core Team A FAIL is still reported though.
After stopping the firewall [service iptables stop], look in the process list and see if "iptables" is still running. It almost looks like it is hanging somewhere.
It is in the list of services shown from the Service Configuration gui (using Gnome - along with showing the rules in place). It is not in a ps -ef|grep iptables output. I cannot see it as a process in the system monitor output either (all processes and dependencies on).
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug and will try and assist you in resolving it if I can. There hasn't been much activity on this bug for a while. Could you tell me if you are still having problems with the latest kernel? If the problem no longer exists then please close this bug or I'll do so in a few days if there is no additional information lodged.
Yes the problem is still present. Kernel 2.6.23.12-52 fc7.
*** Bug 333481 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'. 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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
For sure this bug still lives in at least F8... $ rpm -q iptables kernel iptables-1.3.8-6.fc8 kernel-2.6.24.5-85.fc8 $ sudo service iptables restart iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter nat [ OK ] iptables: Unloading modules: [FAILED] iptables: Applying firewall rules: [ OK ]
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 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. Thank you for reporting this bug and we are sorry it could not be fixed.
Comment #23 notes this is still present in F8: could reporter or maintainer please change version to 8 and re-open, please? (perhaps, given the more aggressive auto-closing of bugs, all those cc'd should be allowed to change version? - the original reporter isn't always still using the same release any more)
I note that #1 says it exists in CentOS (no reference though) but this presumably means it exists in Enterprise too. Also we have seen a similar problem in RHEL4 a few times though that was with 2.6.9-55.0.9.EL and i've not seen it yet with later versions.
You may well be seeing this: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=16fcec35e7d7c4faaa4709f6434a4a25b06d25e3 Prior to this patch there was a deadlock condition between the kernel and userspace as described in that patch. The fix was to fix up our reference counting, and make modprobe non-blocking by default (which is how insmod always works). The down side is that the iptables service can sometimes fail to unload modules. The fix/workaround probably in the best case needs to be for the iptables service script to retry unloading a module after a failure, as it will likely succede on a repetition of the attempt