Bug 103573 - "service iptables stop" either hangs or fails
"service iptables stop" either hangs or fails
Status: CLOSED DUPLICATE of bug 103177
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Thomas Woerner
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2003-09-02 11:44 EDT by Michael Schwendt
Modified: 2007-04-18 12:57 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 13:58:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Schwendt 2003-09-02 11:44:14 EDT
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

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: "
+    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):

How reproducible:

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 09:50:32 EDT
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 09:39:40 EDT

*** This bug has been marked as a duplicate of 103177 ***
Comment 3 Brendan Kelly 2003-09-15 19:07:53 EDT
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 11:16:25 EDT
I also patched my iptables init script and it still hangs.
Comment 5 Red Hat Bugzilla 2006-02-21 13:58:23 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.