[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [Xen-changelog] Detach Xend from terminal, courtesy of Horms <horms@xxxxxxxxxxxx>.


  • To: Anthony Liguori <aliguori@xxxxxxxxxx>
  • From: Kip Macy <kip.macy@xxxxxxxxx>
  • Date: Fri, 9 Dec 2005 15:15:43 -0600
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 09 Dec 2005 21:16:46 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=i5fF8uMe1s9pvqas/8QrZx0RHMjjCquuwR1QFz3JuHndvtZx1HFtS5ueUbHqLpEJt6QK7JQIXjzh8t6epe2Cb61Irq24HKvsxTYYYqyjDYINWhVTQC0DOmDXtUX1tsq43wL2QtfKC90LuVd84Qs1e7Y+JOzB7xd8Jh1+2LU5TfM=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

A  second fork gets you reparented to init.

               -Kip

On 12/9/05, Anthony Liguori <aliguori@xxxxxxxxxx> wrote:
Sorry I missed this on Xen devel, but could someone explain this patch a
little more.  The old behavior purposefully delayed the terminal
detaching until Xend was ready to accept connections.  This is necessary
to avoid a race condition with executing the first xm command after a
xend start.

I don't quite understand why two fork()s would be required to properly
daemonize.  I don't know of any other daemons that do that (certainly,
xenstored and xenconsoled don't).

I could be missing something so if someone could clarify I'd greatly
appreciate it.

Thanks,

Anthony Liguori



Xen patchbot -unstable wrote:

># HG changeset patch
># User emellor@xxxxxxxxxxxxxxxxxxxxxx
># Node ID efc71a3e9f6f7487ad349677369d6221a06ead3f
># Parent  52f214d983fb3edf2e265984ed9fe103dd7d2440
>Detach Xend from terminal, courtesy of Horms <horms@xxxxxxxxxxxx >.
>
>* For setsid to effectively detach a process from the terminal,
>  the following needs to occur:
>
>    fork ()   Return control to the shell
>    setsid () New session with no controlling terminal
>    fork ()   The session leader (parent) exits and thus
>              the resulting child process can never regain the terminal
>
>  This patch adds the second fork
>
>* The call to self.daemonize(), which now forks, is moved to
>  run before self.tracing(), as now that it actually disconnects
>  from the terminal, and thus the prevailing process, the trace
>  loses the processes created in self.run().
>
>Signed-off-by: Ewan Mellor <ewan@xxxxxxxxxxxxx >
>
>diff -r 52f214d983fb -r efc71a3e9f6f tools/python/xen/xend/server/SrvDaemon.py
>--- a/tools/python/xen/xend/server/SrvDaemon.py        Thu Dec  8 16:11:48 2005
>+++ b/tools/python/xen/xend/server/SrvDaemon.py        Thu Dec  8 16:17:53 2005
>@@ -123,9 +123,18 @@
>
>     def daemonize(self):
>         if not XEND_DAEMONIZE: return
>+
>         # Detach from TTY.
>+
>+        # Become the group leader (already a child process)
>         os.setsid()
>
>+        # Fork, this allows the group leader to exit,
>+        # which means the child can never again regain control of the
>+        # terminal
>+        if self.fork_pid(XEND_PID_FILE):
>+            self.exit()
>+
>         # Detach from standard file descriptors, and redirect them to
>         # /dev/null or the log as appropriate.
>         os.close (0)
>@@ -164,7 +173,7 @@
>         # we can avoid a race condition during startup
>
>         r,w = os.pipe()
>-        if self.fork_pid(XEND_PID_FILE):
>+        if os.fork():
>             os.close(w)
>             r = os.fdopen(r, 'r')
>             try:
>@@ -178,6 +187,7 @@
>         else:
>             os.close(r)
>             # Child
>+            self.daemonize ()
>             self.tracing(trace)
>             self.run(os.fdopen(w, 'w'))
>
>@@ -274,7 +284,6 @@
>
>             relocate.listenRelocation()
>             servers = SrvServer.create ()
>-            self.daemonize()
>             servers.start(status)
>         except Exception, ex:
>             print >>sys.stderr, 'Exception starting xend:', ex
>
>_______________________________________________
>Xen-changelog mailing list
>Xen-changelog@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-changelog
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.