Phil Oester <kernel@xxxxxxxxxxxx> schrieb: >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 >xtables-multi. >As an added bonus, since each network namespace has its own socket >pool, an >iptables instance running in one namespace will not lock out an >iptables >instance running in another namespace. A filesystem approach would >have >to recognize and handle multiple network namespaces. > >As long as I was adding locking, I also chose to add a retry loop, with >3 >attempts made to grab the lock before giving up. If I'm not mistaken, we retry failed operations since a few years now, so is this actually still a problem? If so, why abort after three tries instead of waiting until the lock can be acquired? -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
