Bug 1465382 - [UPDATES] ip6tables.service fails to start after uc update to 7.4 is rebooted
[UPDATES] ip6tables.service fails to start after uc update to 7.4 is rebooted
Status: CLOSED DUPLICATE of bug 1460116
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates (Show other bugs)
11.0 (Ocata)
Unspecified Unspecified
medium Severity medium
: ---
: 11.0 (Ocata)
Assigned To: mathieu bultel
Gurenko Alex
: Triaged
: 1463375 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-27 06:43 EDT by Yurii Prokulevych
Modified: 2018-02-19 10:17 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-28 09:38:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3138851 None None None 2017-08-07 17:16 EDT

  None (edit)
Description Yurii Prokulevych 2017-06-27 06:43:11 EDT
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
Comment 2 Emilien Macchi 2017-06-27 08:26:47 EDT
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.
Comment 3 Ihar Hrachyshka 2017-08-22 13:48:43 EDT
This is same as https://bugzilla.redhat.com/show_bug.cgi?id=1481207
Comment 4 Assaf Muller 2017-08-28 09:35:56 EDT
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.
Comment 5 Assaf Muller 2017-08-28 09:38:26 EDT

*** This bug has been marked as a duplicate of bug 1460116 ***
Comment 6 Bob Fournier 2018-02-19 10:17:52 EST
*** Bug 1463375 has been marked as a duplicate of this bug. ***

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