Bug 123501 - stopping iptables saturates system resources...
stopping iptables saturates system resources...
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Depends On:
  Show dependency treegraph
Reported: 2004-05-18 17:25 EDT by Thomas M Steenholdt
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-13 14:53:12 EDT
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 Thomas M Steenholdt 2004-05-18 17:25:47 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)

Description of problem:
After upgrading from FC1 to FC2, i notice that I was unable to reboot
the machine, because it would hang in stopping iptables...
Investigating a little further, the rmmod_r function, runs modprobe -r
to remove all the modules used by iptables, but it seems that modprobe
-r fails in some way or takes a long time to complete... the result is
that on my system (P3) the system will be dead slow for a while, the
processes will start to get killed because or low mem and such...
freshly started server where I did a "ps aux |wc -l" just some seconds
after issuing "service iptables stop" showed more than 4000
processes... most of the modprobe!

I've disabled iptable modules unloading for now, but theres is a
problem around here (perhaps it's really a problem in either modutils
or the kernel, but since it's the iptables script that triggers the
effective denial of service, i've put it here for now)

Please have a look to see it you can reproduce... Or let me know what
kind of information you'd like me to provide...

I have a fresh VMware FC2 where this does not occur!

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
*) note - may not be reproducible on all machines?!?
1. boot
2. run "service iptables stop"

Actual Results:  command doesn't finish and the system resources gets

Expected Results:  command finishes in a sec or so, and there are no
more iptable modules loaded, and the system is still responsive and so on

Additional info:
Comment 1 Andre Robatino 2004-05-21 08:02:33 EDT
  I get a call trace upon shutdown connected to stopping iptables.  I
have a blurry digital photo which is only partially readable.  If the
exact numbers are necessary I can try to take a better picture. 
Unfortunately the info is not logged.  I usually also have another
error message shortly after this, during unmounting disks, something
like "/ is busy".  During the next boot, there are usually orphan
inodes deleted. 
Comment 2 Thomas Woerner 2004-05-21 09:02:11 EDT
This is the old kernel iptables module problem again -> assigning to

In the meantime you can disable module unloading in the iptables
config file /etc/sysconfig/iptables-config by setting
Comment 3 Roland Hermans 2004-05-22 20:40:00 EDT
iptables on my upgraded FC2 partition also has this problem. A fresh
install of FC2 on a different partition of the same PC works just fine.
Comment 4 Roland Hermans 2004-05-23 14:23:42 EDT
In my case the problem as described in the opening text seems to be
caused by a line in my /etc/modules.conf:

above ip_conntrack ip_conntrack_ftp

During the upgrade this line was converted to the following two lines
in /etc/modprobe.conf:

install ip_conntrack /sbin/modprobe --first-time --ignore-install
ip_conntrack && { /sbin/modprobe ip_conntrack_ftp; /bin/true; }
remove ip_conntrack { /sbin/modprobe -r ip_conntrack_ftp; } ;
/sbin/modprobe -r --first-time --ignore-remove ip_conntrack

After commenting out these lines the iptables service no longer gives
any problems during reboot.

I was unaware of the fact that I could add iptables modules to be
(un)loaded to /etc/sysconfig/iptables-config, so I added them to
/etc/modules.conf instead. This worked fine for FC1 but obviously it
doesn't for FC2.
Comment 5 Thomas M Steenholdt 2004-05-23 15:07:10 EDT
I had the same thing... This particular machine has been upgraded more
than once and my settings in modprobe.conf must have been kept since
before there was an iptables-config file. 
Anyway, removing those two lines from modprobe.conf makes everything
work just fine again!
Comment 6 Andre Robatino 2004-05-24 10:01:49 EDT
  I have a clean FC2 install.  The call trace is preceded by the line
(may not be exact)

Stopping iptables : Badness in local_bh_enable at kernel/softirq.c:136
Comment 7 Andre Robatino 2004-06-12 02:27:15 EDT
  Same problem (with same message) exists in kernel-2.6.6-1.427.
Comment 8 Thomas M Steenholdt 2004-06-13 14:53:12 EDT
This was already identified to be a modules.conf->modprobe.conf
upgrade problem... no problem on fresh installs and not a kernel issue!

If this problem should be tracked further, it should be to prevent
similar problem for people who will, in time, upgrade a 2.4 kernel
based rhl/fc release to the NEXT fedora Core release... I don't know
what package is really responsible for the upgrading of the
modules.conf -> modprobe.conf, but i'm suspecting modutils.

I'm closing this bug now (CURRENTRELEASE) as it's really all working
(See comment #4) If anyone disagrees with me, please reopen and change
to proper component!
Comment 9 Andre Robatino 2004-06-14 12:24:59 EDT
  As I already mentioned in comment #6, I have the problem on a clean
install.  In fact, I have two machines with very different hardware
(Microtel SYSMAR561 and Emachines 333cs) with clean installs on both,
and they both have the same call trace.  When I upgraded the kernel on
the Microtel box, the call trace persisted.  I haven't upgraded the
333cs yet.  Whatever this problem is, it is _definitely_ a problem
with clean installs.
Comment 10 Andre Robatino 2004-06-14 12:37:20 EDT
  If this bug is not reopened, the only other component I can think of
that could be causing my call trace would be iptables.  Is that a
reasonable choice for reopening this?  
Comment 11 Thomas M Steenholdt 2004-06-14 14:11:41 EDT
If you guys still has this problem on clean installs... That would
mean that you have some kind of iptables/kernel issue WITHOUT the
messed up modprobe.conf. If this is indeed the case that you should
report that as a new bug, as this bug was submitted for the modprobe
mess problem and the problem you are seeing is something different.
There is a much better chance of having it fixed in reasonable time if
you create a new bug on your exact problem, where you can decsribe the
problem that YOU are experiencing in detail!
Comment 12 Andre Robatino 2004-06-14 14:49:41 EDT
  I discovered my exact problem reported as bug #125731 on June 10, sorry.
Comment 13 Steven Shiau 2005-01-07 11:03:23 EST
I confirm this bug. My smp machine with FC3, kernel
2.6.9-1.724_FC3smp, when I run
/etc/init.d/iptable restart, it hangs. I found it stop at
modprobe -r ipt_MASQUERADE  

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