iptables-restore calls fail acquiring 'xlock' with iptables from master
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Medium
|
Ihar Hrachyshka |
Bug Description
This happens when you use iptables that includes https:/
neutron.
-------
Captured traceback:
~~~~~~~~~~~~~~~~~~~
Traceback (most recent call last):
File "neutron/
File "neutron/
return self.iptables.
File "neutron/
return self._apply()
File "neutron/
first = self._apply_
File "neutron/
'
'.join(log_lines))
File "/usr/lib/
File "/usr/lib/
File "neutron/
File "neutron/
raise ProcessExecutio
neutron.
*filter
:neutron-
:run.py-FORWARD - [0:0]
:run.py-INPUT - [0:0]
:run.py-OUTPUT - [0:0]
:run.
:run.py-local - [0:0]
:run.
:run.
:run.
-I FORWARD 1 -j neutron-filter-top
-I FORWARD 2 -j run.py-FORWARD
-I INPUT 1 -j run.py-INPUT
-I OUTPUT 1 -j neutron-filter-top
-I OUTPUT 2 -j run.py-OUTPUT
-I neutron-filter-top 1 -j run.py-local
-I run.py-FORWARD 1 -m physdev --physdev-out test-veth0bc5b8 --physdev-
-I run.py-FORWARD 2 -m physdev --physdev-in test-veth0bc5b8 --physdev-
-I run.py-INPUT 1 -m physdev --physdev-in test-veth0bc5b8 --physdev-
-I run.py-it-veth0bc5 1 -p ipv6-icmp -m icmp6 --icmpv6-type 130 -j RETURN
-I run.py-it-veth0bc5 2 -p ipv6-icmp -m icmp6 --icmpv6-type 134 -j RETURN
-I run.py-it-veth0bc5 3 -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j RETURN
-I run.py-it-veth0bc5 4 -p ipv6-icmp -m icmp6 --icmpv6-type 136 -j RETURN
-I run.py-it-veth0bc5 5 -m state --state RELATED,ESTABLISHED -m comment --comment "Direct packets associated with a known session to the RETURN chain." -j RETURN
-I run.py-it-veth0bc5 6 -m state --state INVALID -m comment --comment "Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack." -j DROP
-I run.py-it-veth0bc5 7 -m comment --comment "Send unmatched traffic to the fallback chain." -j run.py-sg-fallback
-I run.py-ot-veth0bc5 1 -s ::/128 -d ff02::/16 -p ipv6-icmp -m icmp6 --icmpv6-type 131 -m comment --comment "Allow IPv6 ICMP traffic." -j RETURN
-I run.py-ot-veth0bc5 2 -s ::/128 -d ff02::/16 -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m comment --comment "Allow IPv6 ICMP traffic." -j RETURN
-I run.py-ot-veth0bc5 3 -s ::/128 -d ff02::/16 -p ipv6-icmp -m icmp6 --icmpv6-type 143 -m comment --comment "Allow IPv6 ICMP traffic." -j RETURN
-I run.py-ot-veth0bc5 4 -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m comment --comment "Drop IPv6 Router Advts from VM Instance." -j DROP
-I run.py-ot-veth0bc5 5 -p ipv6-icmp -m comment --comment "Allow IPv6 ICMP traffic." -j RETURN
-I run.py-ot-veth0bc5 6 -p udp -m udp --sport 546 --dport 547 -m comment --comment "Allow DHCP client traffic." -j RETURN
-I run.py-ot-veth0bc5 7 -p udp -m udp --sport 547 --dport 546 -m comment --comment "Prevent DHCP Spoofing by VM." -j DROP
-I run.py-ot-veth0bc5 8 -m state --state RELATED,ESTABLISHED -m comment --comment "Direct packets associated with a known session to the RETURN chain." -j RETURN
-I run.py-ot-veth0bc5 9 -m state --state INVALID -m comment --comment "Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack." -j DROP
-I run.py-ot-veth0bc5 10 -m comment --comment "Send unmatched traffic to the fallback chain." -j run.py-sg-fallback
-I run.py-sg-chain 1 -m physdev --physdev-out test-veth0bc5b8 --physdev-
-I run.py-sg-chain 2 -m physdev --physdev-in test-veth0bc5b8 --physdev-
-I run.py-sg-chain 3 -j ACCEPT
-I run.py-sg-fallback 1 -m comment --comment "Default drop rule for unmatched traffic." -j DROP
COMMIT
# Completed by iptables_manager
# Generated by iptables_manager
*raw
:run.py-OUTPUT - [0:0]
:run.
-I OUTPUT 1 -j run.py-OUTPUT
-I PREROUTING 1 -j run.py-PREROUTING
-I run.py-PREROUTING 1 -m physdev --physdev-in brq7a7f000b-b8 -m comment --comment "Set zone for -veth0bc5b8" -j CT --zone 1
-I run.py-PREROUTING 2 -i brq7a7f000b-b8 -m comment --comment "Set zone for -veth0bc5b8" -j CT --zone 1
-I run.py-PREROUTING 3 -m physdev --physdev-in test-veth0bc5b8 -m comment --comment "Set zone for -veth0bc5b8" -j CT --zone 1
COMMIT
# Completed by iptables_manager
; Stdout: ; Stderr: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
To stay on safe side, we should always call with -w (assuming it's supported by platform).
Changed in neutron: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
tags: | added: functional-tests |
Changed in neutron: | |
assignee: | nobody → Ihar Hrachyshka (ihar-hrachyshka) |
Changed in neutron: | |
assignee: | Ihar Hrachyshka (ihar-hrachyshka) → Jakub Libosvar (libosvar) |
Changed in neutron: | |
assignee: | Jakub Libosvar (libosvar) → Ihar Hrachyshka (ihar-hrachyshka) |
Fix proposed to branch: master /review. openstack. org/495974
Review: https:/