Hi, On Thu, May 13, 2021 at 11:40:47AM +0200, Pablo Neira Ayuso wrote: > On Thu, May 13, 2021 at 06:19:38AM +0000, Dexuan Cui wrote: > > > From: Dexuan Cui > > > Sent: Wednesday, May 12, 2021 11:02 PM > > > > BTW, I found a similar report in 2019: > > > > " > > https://serverfault.com/questions/101022/error-applying-iptables-rules-using-iptables-restore > > I stumbled upon this issue on Ubuntu 18.04. The netfilter-persistent > > service failed randomly on boot while working ok when launched manually. > > Turned out it was conflicting with sshguard service due to systemd trying > > to load everything in parallel. What helped is to setting > > ENABLE_FIREWALL=0 in /etc/default/sshguard and then adding sshguard chain > > and rule manually to /etc/iptables/rules.v4 and /etc/iptables/rules.v6. > > " > > > > The above report provided a workaround. > > There's -w and -W to serialize ruleset updates. You could follow a > similar approach from userspace if you don't use iptables userspace > binary. My guess is the xtables lock is not effective here, so waiting for it probably won't help. Dexuan, concurrent access is avoided in user space using a file-based lock. So if multiple iptables(-restore) processes run in different mount-namespaces, they might miss the other's /run/xtables.lock. Another option would be if libiptc is used instead of calling iptables, but that's more a shot in the dark - I don't know if libiptc doesn't support obtaining the xtables lock. > > I think we need a real fix. > > iptables-nft already fixes this. nftables (and therefore iptables-nft) implement transactional logic in kernel, user space automatically retries if a transaction's commit fails. Cheers, Phil
