[PATCH] Daemonize xcs

[PATCH] Daemonize xcs

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

Currently xcs is run by xend in xen-unstable by simply making it a child
process.  If you launch xend from an ssh session, the session won't exit
because the xcs still is connected to it's controlling terminal.

xcs should daemonize itself to prevent this from happening.  This patch
does that along with making the domain id => port mapping dynamically
allocated.

Regards,
-- 
Anthony Liguori
Linux Technology Center (LTC) - IBM Austin
E-mail: aliguori@us.ibm.com
Phone: (512) 838-1208

Signed-off-by: Anthony Liguori

[-- Attachment #2: xcs_daemon.diff --]
[-- Type: text/x-patch, Size: 3410 bytes --]

--- xen-unstable/tools/xcs/xcs.c	2005-01-25 22:29:13.000000000 -0600
+++ xen-unstable-new/tools/xcs/xcs.c	2005-01-26 15:13:30.606838000 -0600
@@ -74,6 +74,8 @@
 #include <netinet/in.h>
 #include <arpa/inet.h>
 #include <errno.h>
+#include <malloc.h>
+#include <fcntl.h>
 #include "xcs.h"
 
 #undef fd_max
@@ -82,14 +84,36 @@
 /* ------[ Control channel interfaces ]------------------------------------*/
 
 static control_channel_t *cc_list[NR_EVENT_CHANNELS];
-static int dom_to_port[MAX_DOMS]; /* This should not be a fixed-size array.*/
+static int *dom_port_map = 0;
+static int dom_port_map_size = 0;
+
+static void map_dom_to_port(u32 dom, int port)
+{
+	if (dom >= dom_port_map_size) {
+		dom_port_map = (int *)realloc(dom_port_map,
+					      (dom + 10) * sizeof(dom_port_map[0]));
+
+		if (dom_port_map == NULL) {
+			perror("realloc(dom_port_map)");
+			exit(1);
+		}
+
+		for (; dom_port_map_size < dom + 10; dom_port_map_size++) {
+			dom_port_map[dom_port_map_size] = -1;
+		}
+	}
+
+	dom_port_map[dom] = port;
+}
+
+static int dom_to_port(u32 dom) {
+	if (dom >= dom_port_map_size) return -1;
+
+	return dom_port_map[dom];
+}
 
 static void init_interfaces(void)
 {
-    int i;
-    
-    for (i = 0; i < MAX_DOMS; i++)
-        dom_to_port[i] = -1;
     memset(cc_list, 0, sizeof cc_list);
 }
 
@@ -99,9 +123,9 @@
     control_channel_t *cc=NULL, *oldcc;
     int ret;
     
-    if (cc_list[dom_to_port[dom]] != NULL)
+    if (cc_list[dom_to_port(dom)] != NULL)
     {
-        return(cc_list[dom_to_port[dom]]);
+        return(cc_list[dom_to_port(dom)]);
     }
     
     if (cc_list[local_port] == NULL) 
@@ -133,13 +157,13 @@
         {
             DPRINTF("CC conflict! (port: %d, old dom: %u, new dom: %u)\n",
                     cc->local_port, oldcc->remote_dom, cc->remote_dom);
-            dom_to_port[oldcc->remote_dom] = -1;
+            map_dom_to_port(oldcc->remote_dom, -1);
             ctrl_chan_free(cc_list[cc->local_port]);
         }
     }
      
     cc_list[cc->local_port] = cc;
-    dom_to_port[cc->remote_dom] = cc->local_port;
+    map_dom_to_port(cc->remote_dom, cc->local_port);
     cc->type = CC_TYPE_INTERDOMAIN;
     cc->ref_count = 0;
     return cc;
@@ -436,7 +460,7 @@
         if ( cmsg->remote_dom > MAX_DOMS )
             break;
         
-        port = dom_to_port[cmsg->remote_dom];
+        port = dom_to_port(cmsg->remote_dom);
         if (port == -1) break;
         cc = cc_list[port];
         if ((cc != NULL) && ( cc->type == CC_TYPE_INTERDOMAIN ))
@@ -455,7 +479,7 @@
         if ( cmsg->remote_dom > MAX_DOMS )
             break;
         
-        port = dom_to_port[cmsg->remote_dom];
+        port = dom_to_port(cmsg->remote_dom);
         if (port == -1) break;
         cc = cc_list[port];
         if ((cc != NULL) && ( cc->type == CC_TYPE_INTERDOMAIN ))
@@ -627,7 +651,30 @@
     init_bindings();
     
     listen_fd = listen_socket(XCS_TCP_PORT);
-    
+   
+    /* detach from our controlling tty so that a shell does hang waiting for
+       stopped jobs. */
+    /* we should use getopt() here */
+
+    if (!(argc == 2 && !strcmp(argv[1], "-i"))) {
+	pid_t pid = fork();
+	int fd;
+
+	if (pid == -1) {
+		perror("fork()");
+	} else if (pid) {
+		exit(0);
+	}
+
+    	setsid();
+	close(2);
+	close(1);
+	close(0);
+	fd = open("/dev/null", O_RDWR);
+	dup(fd);
+	dup(fd);
+    }
+ 
     for (;;)
     {
         int n, ret;

Re: [PATCH] Daemonize xcs

[Jared Rhine]

> xcs should daemonize itself to prevent this from happening.

Actually, I'd really like an option to keep xend and xensv in the
foreground (and log to stdout), as I want to run them under runit (like
daemontools) for XenCD.  I haven't gotten there yet, but if anyone
touches this code, it'd be nice to leave this possibility open in the
design.

-- 
Jared Rhine <jared@wordzoo.com>



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [PATCH] Daemonize xcs

[Anthony Liguori]

Jared Rhine wrote:

>Actually, I'd really like an option to keep xend and xensv in the
>foreground (and log to stdout), as I want to run them under runit (like
>daemontools) for XenCD.  I haven't gotten there yet, but if anyone
>touches this code, it'd be nice to leave this possibility open in the
>design.
>  
>
I should have mentioned in the note that I also added a -i switch to xcs 
that keeps it in the foreground.  If I'm playing around in Xend and find 
where it daemonizes I'll submit a patch to do the same.  It seems to be 
a pretty standard option in most daemons.

Regards,

-- 
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: [PATCH] Daemonize xcs

[Allen Short]

On Fri, 28 Jan 2005 16:28:13 -0800, Jared Rhine <jared@wordzoo.com> wrote:
>> xcs should daemonize itself to prevent this from happening.
> 
> Actually, I'd really like an option to keep xend and xensv in the
> foreground (and log to stdout), as I want to run them under runit (like
> daemontools) for XenCD.  I haven't gotten there yet, but if anyone
> touches this code, it'd be nice to leave this possibility open in the
> design.

Yes, definitely. Twisted has code for doing daemonization/pidfile management that is much more flexible than xend's current approach. I looked into refactoring it to use that as well as adding support for Twisted's remote-object protocol, but I kept finding things about xend's architecture I wanted to change, so I gave up temporarily :) I will probably revisit this after finishing my current project, which just talks to xend via its HTTP protocol. Basically what needs to be done is to remove entirely the code in SrvDaemon that starts things up, and use 'twistd' to start it instead.

Allen


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl