All of lore.kernel.org
 help / color / mirror / Atom feed
From: Horms <horms@verge.net.au>
To: xen-devel@lists.xensource.com
Subject: Re: [PATCH] setsid() exception in xend
Date: Wed, 30 Nov 2005 02:34:02 +0000 (UTC)	[thread overview]
Message-ID: <dmj32q$9p3$1@sea.gmane.org> (raw)
In-Reply-To: 20051128155701.GB21252@leeni.uk.xensource.com

Sorry if this is a duplicate, I am sure I sent it but
it doesn't seem to have shown up on the list.

On Mon, Nov 28, 2005 at 03:57:01PM +0000, Ewan Mellor wrote:
> On Mon, Nov 28, 2005 at 10:58:09PM +0900, Horms wrote:
> 
> > [Snip!]
> >
> > Sure, I can eliminate the intermediate file descriptor,
> > I'll send a fresh patch tomorrow. 
> 
> That's great, thank you.
> 
> > On a related issue, can you clarify what the race is that it
> > is there to avoid? It seems cumbersome as you point out.
> 
> It means that the xend wrapper, i.e. tools/misc/xend aka /usr/sbin/xend does
> not exit until the daemon is ready to receive commands.  If you were using the
> init.d scripts to start Xend and then start some guest domains, you would have
> a race in that case between daemon startup and the subsequent script that
> would be trying to execute commands at the same time.

Thanks for the clarification.

Below is a patch that removes the unecessary fd handling in
the intermediate parent that was present in my previous patch.
It just calls self.exit(). I did consider doing some fd closing,
but exit() shold be sufficient. I tested this patch and it seems
to work just fine.


# HG changeset patch
# User Horms <horms@verge.net.au>
# Node ID 4c45fd3fd1e0916a34b614c95ca28b7d44cd8e35
# Parent  ddd958718cde22f20371a58359e173fd21c5da2e
[xend] Detach from terminal

* For setsid to effectivley 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 not that it actually disconnects
  from the terminal, and thus the prevailing process, the trace 
  looses the processes created in self.run().

diff -r ddd958718cde -r 4c45fd3fd1e0 tools/python/xen/xend/server/SrvDaemon.py
--- a/tools/python/xen/xend/server/SrvDaemon.py	Mon Nov 28 12:35:11 2005
+++ b/tools/python/xen/xend/server/SrvDaemon.py	Tue Nov 29 01:48:14 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

      parent reply	other threads:[~2005-11-30  2:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-26 11:43 [PATCH] setsid() exception in xend Horms
2005-11-28  4:29 ` Horms
2005-11-28 11:31   ` Ewan Mellor
2005-11-28 12:53     ` Horms
2005-11-28 13:37       ` Ewan Mellor
2005-11-28 13:58         ` Horms
2005-11-28 15:57           ` Ewan Mellor
2005-11-29  1:51             ` Horms
2005-11-30  2:34             ` Horms [this message]

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='dmj32q$9p3$1@sea.gmane.org' \
    --to=horms@verge.net.au \
    --cc=xen-devel@lists.xensource.com \
    /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.