I tested this last change, and it does exactly what we wanted for iptables, the tool. And since that behavior is shared with all tools of the iptables suite, it means iptables-restore got that fix too (good!), but it also introduces a change in behavior for iptables-restore (bad!).
When compared to the bionic 1.6.1 iptables: (a) straight backport from 1.6.2 - iptables loses the implicit -w parameter, meaning it will fail right away if it encounters the lock - iptables-restore maintains the behavior, and grows the extra -w option (b) massaged patches from comment #16 - iptables keeps the same behavior as in 1.6.1 - iptables-restore grows the implicit -w option, meaning it will block until the lock is released The locking code is shared by all tools in one .c file. Making it behave differently whether it's iptables or iptables-restore being used is kumbersome, and would make ubuntu the only one with this behavior. Alternatively, this bug has actually a very decent workaround: wrap iptables-restore in flock. That's the same locking mechanism that iptables itself does, just internally. Quick example: you want iptables-restore -w 2 file.iptables Use: flock -w 2 -x /run/xtables.lock iptables-restore file.iptables You can even augment that a bit with -E <code>, and have flock return <code> if the lock cannot be acquired in the specified amount of time. Of the two patch sets, it feels like (b) introduces the less worse behavior change. Before iptables-restore would fail right away, now it can get stuck for as long as the lock is held. Which is the iptables behavior already. But it's still a change, and your script could stall for as long as the lock exists. You should change it to use -w <seconds>. Option (a) has the danger that if you are not checking for errors in your script, one or more iptables calls could fail, and you wouldn't notice, leaving your firewall incomplete. I think this is a dangerous change. Considering bionic is an LTS, and the existence of the flock workaround which is exactly what the code itself does, what do you guys think about this SRU? Should we pick a patch and go with it, or reject the change and recommend the flock() alternative? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
