Hi Wenxian, On Thu, Nov 15, 2018 at 11:16:49PM +0800, wenxian li wrote: > I was running iptables on different namespaces and met such error > "Another app is currently holding the xtables lock. Perhaps you want > to use the -w option?". > > After googling it, I found this enhancement introduces the lock > mechanism: "xtables: Add locking to prevent concurrent instances". > Based on the commit log, different namespaces should have their own > xtables locks. > > However, based on my test, it looks like different namespaces share > the same lock. > The CLIs below can easily reproduce the issue. > > ip netns exec test1 iptables -L -nv -t mangle & ip netns exec test2 > iptables -L -nv -t mangle & ip netns exec test3 iptables -L -nv -t > mangle & > > I'm wondering is it an expected behavior? Or some kind of bug? The xtables-lock is filesystem-based (via flock()), default lock file name is '/run/xtables.lock'. So despite you run in a different network namespace, the concurrent command invocations will see each other. I am not sure whether this restriction is necessary or not - on one hand different netns' rulesets should not interfere, on the other it might be the ABI which needs protection. Cheers, Phil
