From: Phil Oester <kernel@linuxace.com>
To: netfilter-devel@vger.kernel.org
Cc: pablo@netfilter.org, kaber@trash.net
Subject: [PATCH v3] xtables: Add locking to prevent concurrent instances
Date: Mon, 27 May 2013 12:23:11 -0400 [thread overview]
Message-ID: <20130527162311.GA1366@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]
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.
Phil
Signed-off-by: Phil Oester <kernel@linuxace.com>
---
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
[-- Attachment #2: patch-xtables-lock --]
[-- Type: text/plain, Size: 1353 bytes --]
diff --git a/iptables/xtables-multi.c b/iptables/xtables-multi.c
index 8014d5f..56d2c91 100644
--- a/iptables/xtables-multi.c
+++ b/iptables/xtables-multi.c
@@ -1,8 +1,12 @@
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
+#include <sys/socket.h>
+#include <sys/un.h>
+#include <unistd.h>
#include "xshared.h"
+#include "xtables.h"
#include "xtables-multi.h"
#ifdef ENABLE_IPV4
@@ -35,7 +39,32 @@ static const struct subcommand multi_subcommands[] = {
{NULL},
};
+#define XTMSOCKET_NAME "xtables_multi"
+#define XTMSOCKET_LEN 14
+
int main(int argc, char **argv)
{
+ int i = 0, ret, xtm_socket;
+ struct sockaddr_un xtm_addr;
+
+ memset(&xtm_addr, 0, sizeof(xtm_addr));
+ xtm_addr.sun_family = AF_UNIX;
+ strcpy(xtm_addr.sun_path+1, XTMSOCKET_NAME);
+ xtm_socket = socket(AF_UNIX, SOCK_STREAM, 0);
+ /* If we can't even create a socket, just revert to prior (lockless) behavior */
+ if (xtm_socket < 0)
+ return subcmd_main(argc, argv, multi_subcommands);
+
+ while (1) {
+ ret = bind(xtm_socket, (struct sockaddr*)&xtm_addr,
+ offsetof(struct sockaddr_un, sun_path)+XTMSOCKET_LEN);
+ if (ret == 0)
+ break;
+ if (++i % 5 == 0)
+ fprintf(stderr, "Another app is currently holding the xtables lock; "
+ "waiting for it to exit...\n");
+ sleep(1);
+ }
+
return subcmd_main(argc, argv, multi_subcommands);
}
next reply other threads:[~2013-05-27 16:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-27 16:23 Phil Oester [this message]
2013-05-29 12:59 ` [PATCH v3] xtables: Add locking to prevent concurrent instances Pablo Neira Ayuso
2013-05-29 18:23 ` Phil Oester
2013-05-29 22:28 ` Pablo Neira Ayuso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130527162311.GA1366@gmail.com \
--to=kernel@linuxace.com \
--cc=kaber@trash.net \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.