[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
|