Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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
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.
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.
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.
(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 ?
(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.
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.
(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.
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....
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.
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