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
Version-Release number of selected component (if applicable):
Linux 126.96.36.199-91 with iptables 1.3.8-2.1.fc7. Happened with Linux 188.8.131.52-76
Happens every time iptables stopped
Steps to Reproduce:
1. as root exec /etc/init.d/iptables stop OR stop or restart iptables from
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>
Can you please make a "sh -x /etc/init.d/iptables stop 2>&1" after starting the
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
After a stop of the firewall it is now not possible to restart it. I have to
Second. I see this same problem with a FC6 server too as of this evening.
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
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
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
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
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).
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.
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 184.108.40.206-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:
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
$ 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:
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