Reproduction steps would be: - set up RH-OSP cloud (scenario doesn't really matter as long as it uses reference implementation) - execute tempest suite against it a bunch of times - check that neither of ovs/l3/dhcp agent logs have the error message "Another app is currently holding the xtables lock. Perhaps you want to use the -w option?" on any of the nodes
Seems like this fix didn't work since I do see those errors [root@controller-0 neutron]# grep -iR "Another app is currently" /var/log/neutron/* /var/log/neutron/dhcp-agent.log:Stderr: Another app is currently holding the xtables lock. Perhaps you want to use the -w option? /var/log/neutron/l3-agent.log:Stderr: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
More information is added: Setup 1 Controller and 1 computes Stdin: # Generated by iptables-save v1.4.21 on Fri Oct 6 08:04:35 2017 *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :neutron-dhcp-age-OUTPUT - [0:0] :neutron-dhcp-age-PREROUTING - [0:0] [0:0] -A PREROUTING -j neutron-dhcp-age-PREROUTING [0:0] -A OUTPUT -j neutron-dhcp-age-OUTPUT COMMIT # Completed on Fri Oct 6 08:04:35 2017 # Generated by iptables-save v1.4.21 on Fri Oct 6 08:04:35 2017 *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :neutron-dhcp-age-FORWARD - [0:0] :neutron-dhcp-age-INPUT - [0:0] :neutron-dhcp-age-OUTPUT - [0:0] :neutron-dhcp-age-POSTROUTING - [0:0] :neutron-dhcp-age-PREROUTING - [0:0] :neutron-dhcp-age-mark - [0:0] [0:0] -A PREROUTING -j neutron-dhcp-age-PREROUTING [0:0] -A INPUT -j neutron-dhcp-age-INPUT [0:0] -A FORWARD -j neutron-dhcp-age-FORWARD [0:0] -A OUTPUT -j neutron-dhcp-age-OUTPUT [0:0] -A POSTROUTING -j neutron-dhcp-age-POSTROUTING [0:0] -A neutron-dhcp-age-PREROUTING -j neutron-dhcp-age-mark [0:0] -A neutron-dhcp-age-POSTROUTING -p udp --dport 68 -j CHECKSUM --checksum-fill COMMIT # Completed on Fri Oct 6 08:04:35 2017 # Generated by iptables-save v1.4.21 on Fri Oct 6 08:04:35 2017 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0]:OUTPUT ACCEPT [0:0] :neutron-filter-top - [0:0] :neutron-dhcp-age-FORWARD - [0:0] :neutron-dhcp-age-INPUT - [0:0] :neutron-dhcp-age-OUTPUT - [0:0] :neutron-dhcp-age-local - [0:0] [0:0] -A FORWARD -j neutron-filter-top [0:0] -A OUTPUT -j neutron-filter-top [0:0] -A neutron-filter-top -j neutron-dhcp-age-local [0:0] -A INPUT -j neutron-dhcp-age-INPUT [0:0] -A OUTPUT -j neutron-dhcp-age-OUTPUT [0:0] -A FORWARD -j neutron-dhcp-age-FORWARD COMMIT # Completed on Fri Oct 6 08:04:35 2017 Stdout: Stderr: Another app is currently holding the xtables lock. Perhaps you want to use the -w option? 2017-10-06 08:05:24.706 3816 ERROR neutron.agent.linux.utils [req-5a1f2d93-82e6-4d3b-a0f4-9ff26397557f ] Command: ['ip', 'netns', 'exec', u'qdhcp-4f1ee8df-d696-471e-9576-b5388f52b45d', 'ip', '-4', 'route', 'replace', 'default', 'via', u'10.100.0.17', 'dev', 'tapdfa34054-97']
Toni, please attach DHCP and L3 agent logs with the error so that we can inspect the issue. Note that the iptables command is first executed without -w parameter and then repeated with -w if the first call raised the error. Maybe the error is from the first attempt, and so it may be not a real issue.
OK, I think I understand why it logs the error. This is because we don't pass log_as_error=False on first call to iptables. It's an cosmetic issue since the firewall is still set.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:3069
*** Bug 1545259 has been marked as a duplicate of this bug. ***