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:
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