Bug 123501
Summary: | stopping iptables saturates system resources... | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Thomas M Steenholdt <tmus> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | robatino, rolandh, steven |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
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: | --- | Target Upstream Version: | |
Embargoed: |
Description
Thomas M Steenholdt
2004-05-18 21:25:47 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. 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". 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. 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. 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! 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 Same problem (with same message) exists in kernel-2.6.6-1.427. 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! 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. 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? 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! I discovered my exact problem reported as bug #125731 on June 10, sorry. 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 |