Bug 313051 - iptables modules fail to unload
iptables modules fail to unload
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
i386 Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 333481 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-30 09:20 EDT by Ian
Modified: 2008-06-17 08:55 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 22:32:45 EDT
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 from sh -x /etc/init.d/iptables stop (184 bytes, text/plain)
2007-10-01 05:57 EDT, Ian
no flags Details
2nd log 2> (2.64 KB, text/plain)
2007-10-01 06:01 EDT, Ian
no flags Details
sh -X of /etc/init.d/iptables stop after a start (8.61 KB, text/plain)
2007-10-01 14:49 EDT, Ian
no flags Details
message log of entries from iptables (8.06 KB, text/plain)
2007-10-01 14:50 EDT, Ian
no flags Details
lsmod output for firewall stop and start (10.09 KB, text/plain)
2007-10-02 18:33 EDT, Ian
no flags Details

  None (edit)
Description Ian 2007-09-30 09:20:34 EDT
Description of problem:
Stop or restart of iptables causes error message : unloading iptables modules 
FAILED. 

Version-Release number of selected component (if applicable):
Linux 2.6.22.9-91 with iptables 1.3.8-2.1.fc7. Happened with Linux 2.6.22.5-76 
too.

How reproducible:
Happens every time iptables stopped

Steps to Reproduce:
1. as root exec /etc/init.d/iptables stop OR stop or restart iptables from 
services 
2.
3.
  
Actual results:
Failed message

Expected results:
OK message

Additional info:
None
Comment 1 Ian 2007-09-30 09:23:47 EDT
Just seen this reported for CentOS too.
Comment 2 Thomas Woerner 2007-10-01 04:41:36 EDT
Please attach the output of "sh -x /etc/init.d/iptables stop".
Comment 3 Ian 2007-10-01 05:57:56 EDT
Created attachment 212171 [details]
output from sh -x /etc/init.d/iptables stop
Comment 4 Ian 2007-10-01 06:01:58 EDT
Created attachment 212181 [details]
2nd log 2>

2nd log
Comment 5 Thomas Woerner 2007-10-01 10:00:47 EDT
Can you please make a "sh -x /etc/init.d/iptables stop 2>&1" after starting the
firewall.
Comment 6 Ian 2007-10-01 14:49:27 EDT
Created attachment 212651 [details]
sh -X of /etc/init.d/iptables stop after a start
Comment 7 Ian 2007-10-01 14:50:47 EDT
Created attachment 212661 [details]
message log of entries from iptables
Comment 8 Ian 2007-10-01 14:57:26 EDT
Additional.
After a stop of the firewall it is now not possible to restart it. I have to 
reboot.

Second. I see this same problem with a FC6 server too as of this evening.

Thanks
Comment 9 Thomas Woerner 2007-10-02 05:04:11 EDT
According to comment #7 there are unknown symbols in the netfilter modules. This
is not an iptables problem.

Assigning to kernel.
Comment 10 Chuck Ebbert 2007-10-02 17:49:51 EDT
It seems nf_conntrack_ipv4 isn't getting unloaded. Is it still loaded after the
script fails?
Comment 11 Ian 2007-10-02 18:31:45 EDT
No. It is loaded initially but gets unloaded when iptables stops. It is not 
loaded after the firewall is started again - along with other iptables modules 
that fail. A reboot is needed to the firewall working again. The attachment is 
taken from a FC6 server which is acting in the same way as the F7 one - I 
cannot mess with F7 right now. The results are the same though because I looked 
before.
Comment 12 Ian 2007-10-02 18:33:34 EDT
Created attachment 214161 [details]
lsmod output for firewall stop and start
Comment 13 Ian 2007-10-02 18:35:59 EDT
Comment on attachment 214161 [details]
lsmod output for firewall stop and start

This is FC6 by the way. FC6 is doing exactly what F7 is doing but I cannot stop
and restart f7 right now.
Comment 14 Chuck Ebbert 2007-10-02 18:38:13 EDT
Are there any error messages in the kernel log when it fails to restart?
Comment 15 Ian 2007-10-03 12:52:17 EDT
(In reply to comment #14)
> Are there any error messages in the kernel log when it fails to restart?

The only kernel originated messages have been provided as per comment 7.
Comment 16 Ian 2007-10-06 11:35:36 EDT
These are the latest messages from the message log from the kernel after s atop 
and start of the firewall.

Oct  6 13:09:06 pluto kernel: Removing netfilter NETLINK layer.
Oct  6 13:09:06 pluto kernel: Netfilter messages via NETLINK v0.30.
Oct  6 13:09:06 pluto kernel: nf_conntrack version 0.5.0 (8192 buckets, 65536 
max)
Oct  6 13:09:06 pluto kernel: ip_tables: (C) 2000-2006 Netfilter Core Team

A FAIL is still reported though.
Comment 17 Chuck Ebbert 2007-10-08 18:32:02 EDT
After stopping the firewall [service iptables stop], look in the process list
and see if "iptables" is still running. It almost looks like it is hanging
somewhere.
Comment 18 Ian 2007-10-09 05:25:02 EDT
It is in the list of services shown from the Service Configuration gui (using 
Gnome - along with showing the rules in place). It is not in a ps -ef|grep 
iptables output. I cannot see it as a process in the system monitor output 
either (all processes and dependencies on).
Comment 19 Christopher Brown 2008-01-14 13:08:15 EST
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
Comment 20 Ian 2008-01-15 04:51:22 EST
Yes the problem is still present. Kernel 2.6.23.12-52 fc7.
Comment 21 Christopher Brown 2008-01-15 21:34:32 EST
*** Bug 333481 has been marked as a duplicate of this bug. ***
Comment 22 Bug Zapper 2008-05-14 10:34:41 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'.

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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 23 Curtis Doty 2008-05-14 23:53:37 EDT
For sure this bug still lives in at least F8...

$ rpm -q iptables kernel
iptables-1.3.8-6.fc8
kernel-2.6.24.5-85.fc8
$ sudo service iptables restart
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Setting chains to policy ACCEPT: filter nat      [  OK  ]
iptables: Unloading modules:                               [FAILED]
iptables: Applying firewall rules:                         [  OK  ]
Comment 24 Bug Zapper 2008-06-16 22:32:43 EDT
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 25 Kevin R. Page 2008-06-17 05:25:48 EDT
Comment #23 notes this is still present in F8: could reporter or maintainer
please change version to 8 and re-open, please?

(perhaps, given the more aggressive auto-closing of bugs, all those cc'd should
be allowed to change version? - the original reporter isn't always still using
the same release any more)
Comment 26 Richard Cunningham 2008-06-17 05:32:40 EDT
I note that #1 says it exists in CentOS (no reference though) but this
presumably means it exists in Enterprise too. 

Also we have seen a similar problem in RHEL4 a few times though that was with
2.6.9-55.0.9.EL and i've not seen it yet with later versions.
Comment 27 Neil Horman 2008-06-17 08:55:02 EDT
You may well be seeing this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=16fcec35e7d7c4faaa4709f6434a4a25b06d25e3
Prior to this patch there was a deadlock condition between the kernel and
userspace as described in that patch.  The fix was to fix up our reference
counting, and make modprobe non-blocking by default (which is how insmod always
works).  The down side is that the iptables service can sometimes fail to unload
modules.  The fix/workaround probably in the best case needs to be for the
iptables service script to retry unloading a module after a failure, as it will
likely succede on a repetition of the attempt

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