FS#57459 - [iptables] Race condition when starting services iptables / ip6tables

Attached to Project: Arch Linux
Opened by Bastian Beranek (totsilence) - Saturday, 10 February 2018, 09:59 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Tuesday, 13 February 2018, 18:43 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Ronald van Haren (pressh)
Bartłomiej Piotrowski (Barthalion)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

With iptables 1.6.2-1, linux 4.15.2-2, systemd 237.25-1 I often get (but not always) an error such as this one on boot:

systemctl status iptables.service
● iptables.service - Packet Filtering Framework
Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2018-02-10 10:45:45 CET; 10min ago
Process: 450 ExecStart=/usr/bin/iptables-restore /etc/iptables/iptables.rules (code=exited, status=4)
Main PID: 450 (code=exited, status=4)

Feb 10 10:45:45 beischer-w520 systemd[1]: Starting Packet Filtering Framework...
Feb 10 10:45:45 beischer-w520 iptables-restore[450]: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Feb 10 10:45:45 beischer-w520 systemd[1]: iptables.service: Main process exited, code=exited, status=4/NOPERMISSION
Feb 10 10:45:45 beischer-w520 systemd[1]: iptables.service: Failed with result 'exit-code'.
Feb 10 10:45:45 beischer-w520 systemd[1]: Failed to start Packet Filtering Framework.

Sometimes iptables.service starts up OK but ip6tables.service has the error instead. It appears that two processes are trying to modify the rules table simultaenously?
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Tuesday, 13 February 2018, 18:43 GMT
Reason for closing:  Fixed
Additional comments about closing:  iptables 1.6.2-2
Comment by Bartłomiej Piotrowski (Barthalion) - Monday, 12 February 2018, 12:57 GMT
Could you test if adding After=iptables.service to ip6tables.service makes systemd schedule units correctly?
Comment by Bastian Beranek (totsilence) - Monday, 12 February 2018, 19:32 GMT
Yes that makes things work (I tried 8 boots or so and didn't observe any failures), while 3 boots with the vanilla service file failed reliably.
Comment by Bartłomiej Piotrowski (Barthalion) - Monday, 12 February 2018, 19:37 GMT
Thanks for testing, I will push fixed package tomorrow morning.

Loading...