Bug 333481

Summary: failure upon service stop
Product: [Fedora] Fedora Reporter: Curtis Doty <curtis>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 7CC: chris.brown, eric.fedora, redhat-bugzilla, twoerner
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-16 02:34:31 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 Curtis Doty 2007-10-16 04:18:47 UTC
Description of problem:
# service iptables restart
Flushing firewall rules:                                   [  OK  ]
Setting chains to policy ACCEPT: nat                       [  OK  ]
Unloading iptables modules:                                [FAILED]
Applying iptables firewall rules:                          [  OK  ]

How reproducible:
# cat /etc/sysconfig/iptables
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o ppp+ -j MASQUERADE
COMMIT

That's it. Whenever the system is shutdown or iptables is restarted, you get the
annoying red FAILED.

Brief investigation leads me to think that the initscript fails trying to unload
the nf_conntrack_ipv4 module. Maybe this is because it is implicitly required by
the nat table when no filter table/module is loaded?

Here's the shell script expanded:

# sh -x /etc/init.d/iptables restart
...(snip)...
+ echo -n 'Unloading iptables modules: '
Unloading iptables modules: + ret=0
+ rmmod_r ip_tables
+ local mod=ip_tables
+ local ret=0
+ local ref=
+ '[' 1 = 1 ']'
++ lsmod
++ awk '/^ip_tables/ { print $4; }'
++ tr , ' '
+ ref=iptable_nat
+ for i in '$ref'
+ rmmod_r iptable_nat
+ local mod=iptable_nat
+ local ret=0
+ local ref=
+ '[' 1 = 1 ']'
++ lsmod
++ awk '/^iptable_nat/ { print $4; }'
++ tr , ' '
+ ref=
+ grep -q '^iptable_nat' /proc/modules
+ modprobe -r iptable_nat
+ let ret+=0
+ return 0
+ let ret+=0
+ grep -q '^ip_tables' /proc/modules
+ return 0
+ let ret+=0
+ rmmod_r nf_conntrack_ipv4
+ local mod=nf_conntrack_ipv4
+ local ret=0
+ local ref=
+ '[' 1 = 1 ']'
++ lsmod
++ awk '/^nf_conntrack_ipv4/ { print $4; }'
++ tr , ' '
+ ref=
+ grep -q '^nf_conntrack_ipv4' /proc/modules
+ modprobe -r nf_conntrack_ipv4
+ let ret+=1
+ return 1
+ let ret+=1
+ rmmod_r x_tables
+ local mod=x_tables
+ local ret=0
+ local ref=
+ '[' 1 = 1 ']'
++ lsmod
++ awk '/^x_tables/ { print $4; }'
++ tr , ' '
+ ref=ipt_MASQUERADE
+ for i in '$ref'
+ rmmod_r ipt_MASQUERADE
+ local mod=ipt_MASQUERADE
+ local ret=0
+ local ref=
+ '[' 1 = 1 ']'
++ lsmod
++ awk '/^ipt_MASQUERADE/ { print $4; }'
++ tr , ' '
+ ref=
+ grep -q '^ipt_MASQUERADE' /proc/modules
+ modprobe -r ipt_MASQUERADE
+ let ret+=0
+ return 0
+ let ret+=0
+ grep -q '^x_tables' /proc/modules
+ return 0
+ rmmod_r nf_conntrack
+ local mod=nf_conntrack
+ local ret=0
+ local ref=
+ '[' 1 = 1 ']'
++ lsmod
++ awk '/^nf_conntrack/ { print $4; }'
++ tr , ' '
+ ref='
nf_conntrack_ipv4'
+ for i in '$ref'
+ rmmod_r nf_conntrack_ipv4
+ local mod=nf_conntrack_ipv4
+ local ret=0
+ local ref=
+ '[' 1 = 1 ']'
++ lsmod
++ awk '/^nf_conntrack_ipv4/ { print $4; }'
++ tr , ' '
+ ref=
+ grep -q '^nf_conntrack_ipv4' /proc/modules
+ modprobe -r nf_conntrack_ipv4
+ let ret+=0
+ return 0
+ let ret+=0
+ grep -q '^nf_conntrack' /proc/modules
+ return 0
+ '[' 1 -eq 0 ']'
+ failure
+ local rc=1
+ '[' color '!=' verbose -a -z '' ']'
+ echo_failure
+ '[' color = color ']'
+ echo -en '\033[60G'
                                                           + echo -n '['
[+ '[' color = color ']'
+ echo -en '\033[0;31m'
+ echo -n FAILED
FAILED+ '[' color = color ']'
+ echo -en '\033[0;39m'
+ echo -n ']'
]+ echo -ne '\r'
+ return 1

Comment 1 Thomas Woerner 2007-10-16 09:15:37 UTC
Please post the oiutput of "lsmod | grep conntrack" before and after the
"service iptables stop". Can you manually unload the nf_conntrack_ipv4 module
with "rmmod nf_conntrack_ipv4"? Is there a message in /var/log/messages?

Comment 2 Curtis Doty 2007-10-16 16:17:39 UTC
# lsmod |grep conntrack
nf_conntrack_ipv4      15049  2 iptable_nat
nf_conntrack           63049  4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4
nfnetlink               9945  3 nf_nat,nf_conntrack_ipv4,nf_conntrack

And none are loaded after stop. Do note *two* initial references to
nf_conntrack_ipv4. And that this test case is unusual in that it has nat table
but no filter.

If I restart, and then attempt to manually unload nf_conntrack_ipv4 it will
error with:

ERROR: Module nf_conntrack_ipv4 is in use by iptable_nat

Here's a test/debugging hack that I hope enlightens further:

--- /etc/init.d/iptables.orig   2007-09-19 03:41:35.000000000 -0700
+++ /etc/init.d/iptables        2007-10-16 09:11:06.000000000 -0700
@@ -64,8 +64,12 @@
     # The extra test is for 2.6: The module might have autocleaned,
     # after all referring modules are unloaded.
     if grep -q "^${mod}" /proc/modules ; then
-       modprobe -r $mod > /dev/null 2>&1
+       echo -e "\nDEBUG: unloading $mod..."
+       lsmod |grep conntrack >/tmp/iptables.$$
+       modprobe -r $mod
        let ret+=$?;
+       lsmod |grep conntrack |diff -u /tmp/iptables.$$ -
+       rm /tmp/iptables.$$
     fi
 
     return $ret

# service iptables stop
Flushing firewall rules:                                   [  OK  ]
Setting chains to policy ACCEPT: nat                       [  OK  ]
Unloading iptables modules: 
DEBUG: unloading iptable_nat...
--- /tmp/iptables.5900  2007-10-16 09:11:27.000000000 -0700
+++ -   2007-10-16 09:11:27.267291729 -0700
@@ -1,3 +1,3 @@
-nf_conntrack_ipv4      15049  2 iptable_nat
-nf_conntrack           63049  4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4
+nf_conntrack_ipv4      15049  1 
+nf_conntrack           63049  3 ipt_MASQUERADE,nf_nat,nf_conntrack_ipv4
 nfnetlink               9945  3 nf_nat,nf_conntrack_ipv4,nf_conntrack

DEBUG: unloading nf_conntrack_ipv4...
FATAL: Module nf_conntrack_ipv4 is in use.

DEBUG: unloading ipt_MASQUERADE...
--- /tmp/iptables.5900  2007-10-16 09:11:27.000000000 -0700
+++ -   2007-10-16 09:11:27.483907615 -0700
@@ -1,3 +1,3 @@
-nf_conntrack_ipv4      15049  1 
-nf_conntrack           63049  3 ipt_MASQUERADE,nf_nat,nf_conntrack_ipv4
-nfnetlink               9945  3 nf_nat,nf_conntrack_ipv4,nf_conntrack
+nf_conntrack_ipv4      15049  0 
+nf_conntrack           63049  1 nf_conntrack_ipv4
+nfnetlink               9945  2 nf_conntrack_ipv4,nf_conntrack

DEBUG: unloading nf_conntrack_ipv4...
--- /tmp/iptables.5900  2007-10-16 09:11:27.000000000 -0700
+++ -   2007-10-16 09:11:27.688103378 -0700
@@ -1,3 +0,0 @@
-nf_conntrack_ipv4      15049  0 
-nf_conntrack           63049  1 nf_conntrack_ipv4
-nfnetlink               9945  2 nf_conntrack_ipv4,nf_conntrack
                                                           [FAILED]

Nothing unusual shows up in dmesg.

Comment 3 Thomas Woerner 2007-11-05 15:32:46 UTC
This is netfilter kernel problem. There is a usage count for the conntrack_ipv4
module from the nf_nat module, which is not reported by lsmod.

How to reproduce:
# modprobe nf_conntrack_ipv4
# lsmod | grep nf_conntrack_ipv4
nf_conntrack_ipv4      11717  0 
nf_conntrack           51977  2 nf_conntrack_ipv4,nf_conntrack_ipv6
nfnetlink               8281  3 nf_conntrack_ipv4,nf_conntrack_ipv6,nf_conntrack
# modprobe nf_nat
# lsmod | grep nf_conntrack_ipv4
nf_conntrack_ipv4      11717  1 
nf_conntrack           51977  3 nf_nat,nf_conntrack_ipv4,nf_conntrack_ipv6
nfnetlink               8281  4 nf_nat,nf_conntrack_ipv4,nf_conntrack_ipv6,nf_co
nntrack
# lsmod | grep nf_nat
nf_nat                 18669  0 
nf_conntrack           51977  3 nf_nat,nf_conntrack_ipv4,nf_conntrack_ipv6
nfnetlink               8281  4 nf_nat,nf_conntrack_ipv4,nf_conntrack_ipv6,nf_co
nntrack
# rmmod nf_conntrack_ipv4
ERROR: Module nf_conntrack_ipv4 is in use
# rmmod nf_nat
# rmmod nf_conntrack_ipv4
# 

Assigning to kernel.

This also is a problem for 2.6.23+ in F8 and devel.

Comment 4 Chuck Ebbert 2007-11-08 00:09:08 UTC
Looks like this is fixed in 2.6.23.

Comment 5 Thomas Woerner 2007-11-08 11:26:53 UTC
kernel-2.6.23.1-37.fc8PAE is affected by this problem.


Comment 6 Eric C. Herot 2007-12-05 18:11:36 UTC
kernel-2.6.23.8-63.fc8 is affected by this problem

Comment 7 Christopher Brown 2008-01-16 02:34:31 UTC

*** This bug has been marked as a duplicate of 313051 ***