Bug 1477413 - Firewall fails to apply when using iptables-services
Summary: Firewall fails to apply when using iptables-services
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iptables
Version: 7.4
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: rc
: ---
Assignee: Phil Sutter
QA Contact: Tomas Dolezal
URL:
Whiteboard:
: 1477638 (view as bug list)
Depends On: 1438937 1486803 1544921 1544922 1544923
Blocks: 1420851 1481207
TreeView+ depends on / blocked
 
Reported: 2017-08-02 03:27 UTC by Steven Haigh
Modified: 2021-06-10 12:43 UTC (History)
41 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, at boot time or after running the "systemctl restart iptables ip6tables" command, the systemd service was running both iptables and ip6tables services in parallel. Due to the internal locking mechanism that prevented concurrent updates, one of the two services failed to start. This update adds the --wait option to the "iptables-restore" and "ip6tables-restore" commands to make them wait until the lock becomes free, and the described problem no longer occurs.
Clone Of:
: 1481207 (view as bug list)
Environment:
Last Closed: 2018-04-10 11:28:02 UTC
Target Upstream Version:

Attachments (Terms of Use)
Service wait patch (512 bytes, patch)
2017-08-09 11:29 UTC, Thomas Woerner 		no flags Details | Diff
Service wait patch (1.83 KB, patch)
2017-08-09 13:46 UTC, Thomas Woerner 		no flags Details | Diff
Proposed patch (1.89 KB, patch)
2017-08-09 13:53 UTC, Thomas Woerner 		no flags Details | Diff
Final patch (1.93 KB, patch)
2017-08-09 14:55 UTC, Thomas Woerner 		no flags Details | Diff
Show Obsolete (3) View All Add an attachment (proposed patch, testcase, etc.)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1438597 0 high CLOSED backport iptables-restore --wait patches, --version patch, and iptables -C set_changed() fix 2021-02-22 00:41:40 UTC
Red Hat Knowledge Base (Solution) 3138851 0 None None None 2017-08-03 15:17:32 UTC
Red Hat Product Errata RHEA-2018:0715 0 normal SHIPPED_LIVE iptables bug fix and enhancement update 2018-04-10 16:09:27 UTC

Description Steven Haigh 2017-08-02 03:27:35 UTC 
Description of problem:
I use a very basic firewall applied via the systemd services iptables & ip6tables.

The latest version randomly fails on start with an x-locking issue and suggest the -w option in the failure message.

I fixed this by adding the '-w 1' option to all calls to iptables-restore and ip6tables-restore in /usr/libexec/iptables/*

This seems to reliably fix the problem.

Note: For some reason, just specifying -w complains about a non-numeric option. Maybe something is interacting?

Version-Release number of selected component (if applicable):
iptables-services-1.4.21-18.el7.x86_64
Comment 2 Steven Haigh 2017-08-02 13:00:25 UTC 
Added possibly related backport issue.
Comment 3 Jarno Huuskonen 2017-08-02 13:16:33 UTC 
I have the same problem: after iptables-services-1.4.21-18.el7.x86_64 / iptables-1.4.21-18.el7.x86_64 update:
On server boot either iptables.service or ip6tables.service fails to start with:
iptables.init: iptables: Applying firewall rules: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

and add --wait <num> to /usr/libexec/iptables/* seems to fix this.
Comment 4 Phil Perry 2017-08-05 14:58:16 UTC 
I can confirm this only affects systems where firewalld is disabled and BOTH iptables AND ip6tables are enabled. If, for example, only iptables (IPv4) service is enabled, the service starts fine upon reboot.
Comment 6 Thomas Woerner 2017-08-09 11:29:07 UTC 
Created attachment 1311172 [details]
Service wait patch

Proposed fix to fix the service wait issue with the restore wait patches applied.
Comment 7 Thomas Woerner 2017-08-09 12:26:35 UTC 
*** Bug 1477638 has been marked as a duplicate of this bug. ***
Comment 9 Steven Haigh 2017-08-09 12:58:05 UTC 
With the update to iptables, I wonder if it makes sense to include -W 100 as well.

The man page shows:
       -W, --wait-interval microseconds
              Interval  to  wait  per  each iteration.  When running latency sensitive applications, waiting for the xtables lock for extended durations may not be acceptable. This option will make each iteration take the amount of
              time specified. The default interval is 1 second. This option only works with -w.

The default wait period will be 1 second otherwise.
Comment 10 Jarno Huuskonen 2017-08-09 13:04:23 UTC 
(In reply to Thomas Woerner from comment #6)
> Created attachment 1311172 [details]
> Service wait patch
> 
> Proposed fix to fix the service wait issue with the restore wait patches
> applied.

Doesn't ip6tables.init need same --wait patch ?
Comment 11 Thomas Woerner 2017-08-09 13:15:30 UTC 
(In reply to Jarno Huuskonen from comment #10)
> (In reply to Thomas Woerner from comment #6)
> > Created attachment 1311172 [details]
> > Service wait patch
> > 
> > Proposed fix to fix the service wait issue with the restore wait patches
> > applied.
> 
> Doesn't ip6tables.init need same --wait patch ?

This is a build environment patch. ip6tables.init script is generated out of the iptables.init script.
Comment 12 Thomas Woerner 2017-08-09 13:46:03 UTC 
Created attachment 1311235 [details]
Service wait patch

Enhanced patch version using iptables-config settings
Comment 13 Thomas Woerner 2017-08-09 13:53:07 UTC 
Created attachment 1311237 [details]
Proposed patch

Enhanced documentation for IPTABLES_RESTORE_WAIT_INTERVAL
Comment 14 Steven Haigh 2017-08-09 13:58:37 UTC 
Thumbs up from me on patch v3.

Having the ability to tweak down the retry is fantastic - otherwise large firewall rulesets may take quite some time to apply.
Comment 16 Thomas Woerner 2017-08-09 14:55:02 UTC 
Created attachment 1311251 [details]
Final patch

Using microseconds properly for the --wait-interval option.
Comment 20 Robert Scheck 2017-08-24 17:37:58 UTC 
I can not see how attachment #1311251 [details] would actually do anything until
it is explicitly configured. Shouldn't there be any proper default?
Comment 21 Robert Scheck 2017-08-24 18:50:00 UTC 
(In reply to Robert Scheck from comment #20)
> I can not see how attachment #1311251 [details] would actually do anything
> until it is explicitly configured. Shouldn't there be any proper default?

Sorry, I overlooked the second chunk of the patch.
Comment 22 Steven Haigh 2017-08-28 16:02:48 UTC 
Hi all,

Just wanted to give this a bit of a nudge....

There's a growing number of RHEL 7.4 systems on the internet where the firewall is currently failing to load....
Comment 25 ileppala 2017-09-22 06:35:06 UTC 
Hi all,

Just wanted to give this yet another nudge...

Because of reasons mentioned by Steven Haigh
Comment 26 Tomas Dolezal 2017-09-22 12:23:32 UTC 
This issue is being addressed in 7.4.2 batch zstream, the reference is bug 1481207
Comment 27 Steven Haigh 2017-09-22 12:58:35 UTC 
Is there any indication of a timeframe for that release?
Comment 28 Tomas Dolezal 2017-09-22 13:43:46 UTC 
I am afraid I cannot give you an exact date, but as said on https://access.redhat.com/solutions/401413 the asynchronous updates are released in weeks timeframe. This is planned for the next batch as the last one was missed due to incomplete fixes.

If you need better information, please contact our support where you can request the package as a hotfix.
Comment 29 Trevor Cordes 2017-09-24 21:41:31 UTC 
This is happening to me (I think it's this bug) on Fedora 26.  Are the fixes going into Fedora also?
Comment 33 errata-xmlrpc 2018-04-10 11:28:02 UTC 
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/RHEA-2018:0715
Note You need to log in before you can comment on or make changes to this bug.