Bug 442335 - iptables modules fail to unload
iptables modules fail to unload
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
i686 Linux
low Severity low
: ---
: ---
Assigned To: Neil Horman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-14 09:47 EDT by Matt Castelein
Modified: 2008-12-21 19:39 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-21 19:39:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of sh -x /etc/init.d/iptables stop (9.22 KB, text/plain)
2008-05-08 09:39 EDT, Matt Castelein
no flags Details
/etc/sysconfig/iptables-config (1.70 KB, text/plain)
2008-05-08 10:38 EDT, Matt Castelein
no flags Details
lsmod_before (3.66 KB, text/plain)
2008-05-08 12:18 EDT, Matt Castelein
no flags Details
lsmod_after (3.03 KB, text/plain)
2008-05-08 12:20 EDT, Matt Castelein
no flags Details
trace files created during test (4.21 KB, application/octet-stream)
2008-05-09 13:04 EDT, Matt Castelein
no flags Details

  None (edit)
Description Matt Castelein 2008-04-14 09:47:13 EDT
Description of problem: iptables modules fail to unload


Version-Release number of selected component (if applicable):
iptables-1.3.8-6.fc8

How reproducible: Always


Steps to Reproduce:
1.stop or restart iptables
  
Actual results:
iptables: Unloading modules:                               [FAILED]
Comment 1 Thomas Woerner 2008-05-08 07:26:13 EDT
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.
Comment 2 Matt Castelein 2008-05-08 09:39:32 EDT
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.
Comment 3 Thomas Woerner 2008-05-08 10:12:00 EDT
Oups, I am sorry - I mean: /etc/sysconfig/system-config-firewall
Comment 4 Matt Castelein 2008-05-08 10:15:30 EDT
/etc/sysconfig/system-config-firewall doesn't exist either.
Comment 5 Matt Castelein 2008-05-08 10:38:48 EDT
Created attachment 304868 [details]
/etc/sysconfig/iptables-config
Comment 6 Thomas Woerner 2008-05-08 11:08:01 EDT
Are you using firestarter?
Comment 7 Matt Castelein 2008-05-08 11:11:03 EDT
No, never heard of it, aside from the Prodigy song. :-)
Comment 8 Thomas Woerner 2008-05-08 11:36:10 EDT
Please add the output of lsmod before (reboot needed) and after stopping the
firewall.

This is a netfilter kernel problem.
Comment 9 Matt Castelein 2008-05-08 12:18:59 EDT
Created attachment 304874 [details]
lsmod_before

lsmod output after reboot, before unloading firewall.
Comment 10 Matt Castelein 2008-05-08 12:20:05 EDT
Created attachment 304875 [details]
lsmod_after

Output of lsmod after stopping firewall.
Comment 11 Thomas Woerner 2008-05-09 08:36:09 EDT
This is a kernel problem.

Assigning to kernel.
Comment 12 Neil Horman 2008-05-09 08:57:11 EDT
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!
Comment 13 Thomas Woerner 2008-05-09 09:22:21 EDT
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.
Comment 14 Matt Castelein 2008-05-09 09:52:28 EDT
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
Comment 15 Neil Horman 2008-05-09 10:36:59 EDT
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!

Comment 16 Matt Castelein 2008-05-09 10:56:48 EDT
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]
Comment 17 Neil Horman 2008-05-09 12:45:41 EDT
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!
Comment 18 Matt Castelein 2008-05-09 13:04:48 EDT
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?
Comment 19 Bug Zapper 2008-11-26 05:29:35 EST
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
Comment 20 Matt Castelein 2008-12-21 17:41:38 EST
FYI: I have since updated to 10, and this bug no longer appears.
Comment 21 Neil Horman 2008-12-21 19:39:18 EST
k, closing.

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