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
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
|
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
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
Comment by
Bastian Beranek (totsilence) -
Monday, 12 February 2018, 19:32 GMT
Comment by
Bartłomiej Piotrowski (Barthalion)
- Monday, 12 February 2018, 19:37 GMT
Could you test if adding After=iptables.service to
ip6tables.service makes systemd schedule units correctly?
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.
Thanks for testing, I will push fixed package tomorrow morning.