Bug 103573

Summary: "service iptables stop" either hangs or fails
Product: [Retired] Red Hat Linux Reporter: Michael Schwendt <bugs.michael>
Component: kernelAssignee: Thomas Woerner <twoerner>
Status: CLOSED DUPLICATE QA Contact: Ben Levenson <benl>
Severity: high Docs Contact:
Priority: medium    
Version: 7.3CC: cefrodrigues, me
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 18:58:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michael Schwendt 2003-09-02 15:44:14 UTC
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?

Comment 1 Carlos Rodrigues 2003-09-07 13:50:32 UTC
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%.

Comment 2 Thomas Woerner 2003-09-11 13:39:40 UTC

*** This bug has been marked as a duplicate of 103177 ***

Comment 3 Brendan Kelly 2003-09-15 23:07:53 UTC
I updated my iptables init script as per above suggested workaround and it 
works quite happily for me.

Comment 4 Carlos Rodrigues 2003-09-17 15:16:25 UTC
I also patched my iptables init script and it still hangs.

Comment 5 Red Hat Bugzilla 2006-02-21 18:58:23 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.