From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: The iptables-1.2.8-8.72.3 erratum for Valhalla fails reproducibly with my configuration upon running "service iptables stop". [...] Case 1: It locks up in "Unloading iptables modules" with rmmod using 99.9% of the CPU power and lsmod showing only ip_conntrack and "(deleted)" in the status column. In /etc/sysconfig/iptables-config I load these custom modules: IPTABLES_MODULES="ip_conntrack_ftp ip_nat_ftp ip_conntrack_irc ip_nat_irc" The complete set of netfilter modules loaded is as follows: ip_nat_irc 3360 0 (unused) ip_conntrack_irc 4256 1 ip_nat_ftp 4000 0 (unused) ip_conntrack_ftp 5088 1 ipt_REJECT 4000 2 (autoclean) ipt_state 1344 12 (autoclean) iptable_filter 2528 1 (autoclean) ipt_limit 1728 7 (autoclean) ipt_LOG 4384 17 (autoclean) ipt_MASQUERADE 2336 1 (autoclean) iptable_nat 21844 3 (autoclean) [ip_nat_irc ip_nat_ftp ipt_MASQUERADE] ip_conntrack 26100 4 (autoclean) [ip_nat_irc ip_conntrack_irc ip_nat_ftp ip_conntrack_ftp ipt_state ipt_MASQUERADE iptable_nat] ipt_TOS 1856 4 (autoclean) iptable_mangle 3040 1 (autoclean) ip_tables 13760 11 [ipt_REJECT ipt_state iptable_filter ipt_limit ipt_LOG ipt_MASQUERADE iptable_nat ipt_TOS iptable_mangle] [...] Case 2: With a different set of modules loaded, it does not even unload as many modules, but prints "[FAILED]" upon "service iptables stop", because the iptable_nat module is still in use due to conntrack modules which have not been removed earlier. [...] To fix both cases, I've added this rather trivial safety code to the most recent version of iptables initscript from Raw Hide: --- iptables.init.orig 2003-07-19 19:24:22.000000000 +0200 +++ iptables.init 2003-09-02 16:49:10.000000000 +0200 @@ -175,6 +175,10 @@ echo -n $"Unloading $IPTABLES modules: " ret=0 + for mod in $IPTABLES_MODULES; do + rmmod_r $mod + let ret+=$?; + done rmmod_r ${IPV}_tables let ret+=$?; rmmod_r ${IPV}_conntrack Version-Release number of selected component (if applicable): iptables-1.2.8-8.72.3 How reproducible: Always Steps to Reproduce: - Additional info: * Not reproducible with up-to-date Shrike (plus iptables from Raw Hide) and neither with Severn 9.0.93-4. * I'm aware that my patch probably only works around the real problem -- kernel bug maybe?
I am also seeing the same behaviour on Red Hat 8.0 with kernel-2.4.20-20.8 after upgrading to iptables-1.2.8-8.80.2. This does not happen everytime, only about 75%.
*** This bug has been marked as a duplicate of 103177 ***
I updated my iptables init script as per above suggested workaround and it works quite happily for me.
I also patched my iptables init script and it still hangs.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.