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: ASSIGNED
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates (Show other bugs)
11.0 (Ocata)
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: mathieu bultel
Gurenko Alex
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-27 06:43 EDT by Yurii Prokulevych
Modified: 2017-08-07 17:16 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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.

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