There have been numerous complaints and bug reports over the years when admins attempt to run more than one instance of iptables simultaneously. Currently open bug reports which are related: 325: Parallel execution of the iptables is impossible 758: Retry iptables command on transient failure 764: Doing -Z twice in parallel breaks counters 822: iptables shows negative or other bad packet/byte counts As Patrick notes in 325: "Since this has been a problem people keep running into, I'd suggest to simply add some locking to iptables to catch the most common case." I started looking into alternatives to add locking, and of course the most common/obvious solution is to use a pidfile. But this has various downsides, such as if the application is terminated abnormally and the pidfile isn't cleaned up. And this also requires a writable filesystem. Using a UNIX domain socket file (e.g. in /var/run) has similar issues. Starting in 2.2, Linux added support for abstract sockets. These sockets require no filesystem, and automatically disappear once the application terminates. This is the locking solution I chose to implement in ip[6]tables. As an added bonus, since each network namespace has its own socket pool, an ip[6]tables instance running in one namespace will not lock out an ip[6]tables instance running in another namespace. A filesystem approach would have to recognize and handle multiple network namespaces. Phil Signed-off-by: Phil Oester --- v2: Addressed Patrick's comments - locking attempts will be made indefinitely until successful v3: Update warning message to more closely resemble locking output from yum v4: Move lock to ip[6]tables only. Add -w option to wait for lock - default is to only try once then exit