Description of problem: ----------------------- systemctl status ip6tables.service ● ip6tables.service - IPv6 firewall with ip6tables Loaded: loaded (/usr/lib/systemd/system/ip6tables.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2017-06-27 05:38:46 EDT; 57min ago Process: 679 ExecStart=/usr/libexec/iptables/ip6tables.init start (code=exited, status=1/FAILURE) Main PID: 679 (code=exited, status=1/FAILURE) Jun 27 05:38:46 undercloud-0.redhat.local systemd[1]: Starting IPv6 firewall with ip6tables... Jun 27 05:38:46 undercloud-0.redhat.local ip6tables.init[679]: ip6tables: Applying firewall rules: Another app is currently holding the xtables lock. Perhaps you want to use the -w option? Jun 27 05:38:46 undercloud-0.redhat.local ip6tables.init[679]: [FAILED] Jun 27 05:38:46 undercloud-0.redhat.local systemd[1]: ip6tables.service: main process exited, code=exited, status=1/FAILURE Jun 27 05:38:46 undercloud-0.redhat.local systemd[1]: Failed to start IPv6 firewall with ip6tables. Jun 27 05:38:46 undercloud-0.redhat.local systemd[1]: Unit ip6tables.service entered failed state. Jun 27 05:38:46 undercloud-0.redhat.local systemd[1]: ip6tables.service failed. Version-Release number of selected component (if applicable): ------------------------------------------------------------- iptables-services-1.4.21-18.el7.x86_64 openstack-tripleo-heat-templates-6.0.0-12.el7ost.noarch openstack-tripleo-validations-5.5.0-1.el7ost.noarch python-tripleoclient-6.1.0-6.el7ost.noarch puppet-tripleo-6.3.0-12.el7ost.noarch openstack-tripleo-common-6.0.0-8.el7ost.noarch openstack-tripleo-puppet-elements-6.0.0-3.el7ost.noarch openstack-tripleo-image-elements-6.0.0-2.el7ost.noarch openstack-tripleo-ui-3.1.0-9.el7ost.noarch Steps to Reproduce: 1. Install RHOS-11 2. Setup repos (rhos-release -P 11 -p 7.4-testing -r 7.4) 3. Update uc 4. Reboot uc Actual results: --------------- Service is failed
It sounds like an issue where IPtables (v6) tries to start while another process of IPtables (probably v4) is already managing the rules. I've done a bit of research and it seems like TripleO already use --wait option when using IPtables, since the iptables 1.4.20 (we have 1.4.21 in RHEL 7.4): https://github.com/puppetlabs/puppetlabs-firewall/blob/b0e45f8ca06874b500b65dd36ab1dd838aed5826/lib/puppet/provider/firewall/iptables.rb#L651-L657 Since you hit that at reboot, I think we need to change the iptables.init (in packaging) to start the process with --wait if possible, so we avoid a race condition where iptables starts in the same time as ip6tables. At this stage, we should probably reach out IPtables maintainers to get their feedback.
This is same as https://bugzilla.redhat.com/show_bug.cgi?id=1481207
We discussed this on a Networking DFG triage call, we don't see anything we can do here but to ping on the dependent iptables RHBZ.
*** This bug has been marked as a duplicate of bug 1460116 ***
*** Bug 1463375 has been marked as a duplicate of this bug. ***