Bug 442335

Please attach /etc/sysconfig/system/config/firewall to this bugzilla.
Please also attach the output of "sh -x /etc/init.d/iptables stop" after you
have started the firewall.

Created attachment 304862 [details]
output of sh -x /etc/init.d/iptables stop

This is the output of sh -x /etc/init.d/iptables stop..

The file /etc/sysconfig/system/config/firewall does not exist.

Oups, I am sorry - I mean: /etc/sysconfig/system-config-firewall

/etc/sysconfig/system-config-firewall doesn't exist either.

Created attachment 304868 [details]
/etc/sysconfig/iptables-config

Are you using firestarter?

No, never heard of it, aside from the Prodigy song. :-)

Please add the output of lsmod before (reboot needed) and after stopping the
firewall.

This is a netfilter kernel problem.

Created attachment 304874 [details]
lsmod_before

lsmod output after reboot, before unloading firewall.

Created attachment 304875 [details]
lsmod_after

Output of lsmod after stopping firewall.

This is a kernel problem.

Assigning to kernel.

I think what you're seeing is this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=16fcec35e7d7c4faaa4709f6434a4a25b06d25e3
If you go back to the origional Feora 8 GA kernel, does the problem exist?  If
not, I'm almost certain thats what you're seeing.  There was a deadlock problem
in the kernel back then that resulted from a recursive resource grab between a
user space file lock and a kernel reference count.  The only way to fix it was
the above patch, which, as a side affect causes the unloading of iptables
modules to fail in the event they are still in use during unload (its unsafe to
block on them to unload).

If thats the case then the fix for this does in fact need to be in the iptables
service init script.  It will be sufficient to simply retry the module unload
operation from in that script.  Please retest with the GA kernel and let me know
if the problem subsides.  If it does, I'll write a patch for the iptables module
and return this to the iptables component.  Thanks!

The problem is the "rmmod nf_conntrack_ipv4", which fails. Please have a look at
the attachments for comments #2 and #9. You will see that all dependant modules
from nf_conntrack_ipv4" are already removed before the rmmod of
nf_conntrack_ipv4 itself.

I am not certain what "GA kernel" refers to, sorry.. I have these kernels..

kernel-2.6.23.8-63.fc8
kernel-2.6.23.9-85.fc8
kernel-2.6.23.14-107.fc8
kernel-2.6.23.14-115.fc8
kernel-2.6.23.15-137.fc8
kernel-2.6.24.3-12.fc8
kernel-2.6.24.3-34.fc8
kernel-2.6.24.3-50.fc8
kernel-2.6.24.4-64.fc8
kernel-2.6.24.5-85.fc8

kernel-2.6.23.8-63.fc8 will do fine, thank you.  FYI, when you do this test, it
is possible that you will see a hang in the service iptables stop command,
rather than just a failure (hence the upstream patch)

Also, can you tell me, in the attachment from comments 9 and 10, when you
stopped the firewall during that specific test, did the service iptables stop
command fail or succede? \

More generally, does that command always fail in your environment, or just
sometimes?  I ask because in comment 10, your lsmod output shows now
nf_contrack_* modules all missing from the output of lsmod (which is the
nominally expected case), yet the output from comment 2 shows that a grep of
/proc/modules (from which the output of lsmod is derived) found that module to
exist after the unload operation completed in the service utility.  So the two
attachments are in my mind, conflicting, unless the service iptables stop
routine only fails sometimes.  Thanks!

stopping the service always reports a failure to unload the modules on my system.

I will attempt the test now..

I am now running kernel-2.6.23.8-63.fc8 and unloading modules failed.

[root@arturo ~]# uname -r
2.6.23.8-63.fc8
[root@arturo ~]# service iptables stop
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Setting chains to policy ACCEPT: filter mangle na[  OK  ]
iptables: Unloading modules:                               [FAILED]

hmm, then I stand corrected, this is in fact a different problem.  I'm confused
though, since the service fails because after unloading all the modules with a
modprobe -r there is still a module left in /proc/modules.  However a manual
read of proc/modules a short time later results in that same module being gone.

Another possibility is that a somehow modprobe attempts to remove a module that
is already gone.  That would explain why it doesn't show up in /proc/modules. 
If modprobe calls delete_module on a non-existant module, ENOENT is returned
from the kernel and modprobe exits with  code 1, which is what you're seeing in
your script trace from comment 2.  That would all make sense (although extra
flags have to be passed to modprobe to make that happen normally I think).  What
version of module-init-tools are you using?

Lets try something, if we could please.  In /etc/init.d/iptables, find this line:
modprobe -r $mod > /dev/null 2>&1
and replace it with this line:
/usr/bin/strace -o /tmp/modprobe.strace.$mod modprobe -r $mod > /dev/null 2>&1

Please  re-run your test then.  Afterward, there should be several files in temp
with the straces from the various modprobe runs.  This will confirm for us why
modprobe is exiting with a non-zero return code, and give me a good idea of how
to fix this.  Thanks!

Created attachment 304967 [details]
trace files created during test

I ran this with kernel 2.6.24.5-85.fc8 and module-init-tools-3.4-2.fc8
it said unloading modules OK!!	If I switch back the initscript it fails again.

Did you want to run it with the older kernel?

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

FYI: I have since updated to 10, and this bug no longer appears.

k, closing.