On Wed, May 29, 2013 at 02:59:03PM +0200, Pablo Neira Ayuso wrote: > I think we can: > > * Add a new option to explicitly request this behaviour, just as a way > to assert that you really want iptables to retry. Harald was rising > some concerns on the expected results in case of clash that sound > reasonable to me. I agree that the retry behaviour could be made optional, however I'm not sure that the locking behaviour should be optional. It leads to various races, some of which are subtle and can occur during if-up and other "behind the scenes" scenarios. In my personal experience, I had to implement locking inside my scripts because I was hitting races fairly regularly with dynamic rule additions/deletions (and I suspect other admins have done the same). Perhaps we can change the error to say: "Another app is currently holding the ip[6]tables lock (use -r option to enable retries)" or something similar? At least that is more informative than the typical race error of "iptables: Resource temporarily unavailable". > * Limit this to ip[6]tables. All bug reports refer to it. Seems reasonable. If future races are discovered in -save or -restore, it could be easily changed. Phil -- 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
