Bug 123501 - stopping iptables saturates system resources...
Summary: stopping iptables saturates system resources...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 2
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-05-18 21:25 UTC by Thomas M Steenholdt
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-13 18:53:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Thomas M Steenholdt 2004-05-18 21:25:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040514

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):
iptables-1.2.9-2.3.1

How reproducible:
Always

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

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

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 12:02:33 UTC
  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 13:02:11 UTC
This is the old kernel iptables module problem again -> assigning to
kernel.

In the meantime you can disable module unloading in the iptables
config file /etc/sysconfig/iptables-config by setting
IPTABLES_MODULES_UNLOAD="no".

Comment 3 Roland Hermans 2004-05-23 00:40:00 UTC
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 18:23:42 UTC
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 19:07:10 UTC
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 14:01:49 UTC
  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 06:27:15 UTC
  Same problem (with same message) exists in kernel-2.6.6-1.427.

Comment 8 Thomas M Steenholdt 2004-06-13 18:53:12 UTC
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 16:24:59 UTC
  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 16:37:20 UTC
  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 18:11:41 UTC
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 18:49:41 UTC
  I discovered my exact problem reported as bug #125731 on June 10, sorry.

Comment 13 Steven Shiau 2005-01-07 16:03:23 UTC
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.