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

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

[Anthony Liguori]

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@leeni.uk.xensource.com
># Node ID efc71a3e9f6f7487ad349677369d6221a06ead3f
># Parent  52f214d983fb3edf2e265984ed9fe103dd7d2440
>Detach Xend from terminal, courtesy of Horms <horms@verge.net.au>.
>
>* 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@xensource.com>
>
>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@lists.xensource.com
>http://lists.xensource.com/xen-changelog
>
>  
>

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

[Kip Macy]

[-- Attachment #1.1: Type: text/plain, Size: 3684 bytes --]

A  second fork gets you reparented to init.

               -Kip

On 12/9/05, Anthony Liguori <aliguori@us.ibm.com> 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@leeni.uk.xensource.com
> ># Node ID efc71a3e9f6f7487ad349677369d6221a06ead3f
> ># Parent  52f214d983fb3edf2e265984ed9fe103dd7d2440
> >Detach Xend from terminal, courtesy of Horms <horms@verge.net.au>.
> >
> >* 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@xensource.com>
> >
> >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@lists.xensource.com
> >http://lists.xensource.com/xen-changelog
> >
> >
> >
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 6641 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

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

[Ewan Mellor]

On Fri, Dec 09, 2005 at 02:47:43PM -0600, Anthony Liguori 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).

It's a standard technique on Unixen.  You need to fork before calling setsid
to ensure that you are not a process group leader, then afterwards to ensure
that children cannot regain the terminal.  See

http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC16

(If xenstored and xenconsoled aren't doing this, then they ought to.)

We have preserved the behaviour whereby the Xend process does not exit until it
is ready to accept connections -- it's just one fork further on (and there's
a patch with another fork on its way, for your amusement, but that's a different
story ;-)

Ewan. 

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

[Anthony Liguori]

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

Ewan Mellor wrote:

>>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).
>>    
>>
>
>It's a standard technique on Unixen.  You need to fork before calling setsid
>to ensure that you are not a process group leader, then afterwards to ensure
>that children cannot regain the terminal.  See
>  
>
I see, I've only ever needed this behavior once and did something 
embarrassingly more complex to achieve it :-)  While not necessary for 
xenconsoled and xenstored, it certainly doesn't hurt.

>http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC16
>
>(If xenstored and xenconsoled aren't doing this, then they ought to.)
>  
>
Patch is attached.

>We have preserved the behaviour whereby the Xend process does not exit until it
>is ready to accept connections -- it's just one fork further on (and there's
>a patch with another fork on its way, for your amusement, but that's a different
>story ;-)
>  
>
So that Xend can restart itself?  Yeah, I saw that one :-)  I'll reserve 
a commen there.   Thanks for the explaination!

Regards,

Anthony Liguori

>Ewan. 
>
>  
>


[-- Attachment #2: 8312_setsid_fork.diff --]
[-- Type: text/plain, Size: 1302 bytes --]

# HG changeset patch
# User Anthony Liguori <anthony@codemonkey.ws>
# Node ID e55633c669d11b48cf16d0ddaebbb836d7b3f5f6
# Parent  53cff3f88e45cb5230da39f86d84b6606da0cdbb
Make sure to fork again after setsid() so that child cannot regain CTTY.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

diff -r 53cff3f88e45 -r e55633c669d1 tools/console/daemon/utils.c
--- a/tools/console/daemon/utils.c	Fri Dec  9 11:05:06 2005 +0000
+++ b/tools/console/daemon/utils.c	Fri Dec  9 16:33:01 2005 -0500
@@ -90,6 +90,12 @@
 
 	setsid();
 
+	if ((pid = fork()) > 0) {
+		exit(0);
+	} else if (pid == -1) {
+		err(errno, "fork() failed");
+	}
+
 	/* redirect fd 0,1,2 to /dev/null */
 	if ((fd = open("/dev/null",O_RDWR)) == -1) {
 		exit(1);
diff -r 53cff3f88e45 -r e55633c669d1 tools/xenstore/xenstored_core.c
--- a/tools/xenstore/xenstored_core.c	Fri Dec  9 11:05:06 2005 +0000
+++ b/tools/xenstore/xenstored_core.c	Fri Dec  9 16:33:01 2005 -0500
@@ -1491,6 +1491,13 @@
 
 	/* Session leader so ^C doesn't whack us. */
 	setsid();
+
+	/* Let session leader exit so child cannot regain CTTY */
+	if ((pid = fork()) < 0)
+		barf_perror("Failed to fork daemon");
+	if (pid != 0)
+		exit(0);
+
 #ifndef TESTING	/* Relative paths for socket names */
 	/* Move off any mount points we might be in. */
 	chdir("/");

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

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

[Ewan Mellor]

On Fri, Dec 09, 2005 at 03:35:27PM -0600, Anthony Liguori wrote:

> >http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC16
> >
> >(If xenstored and xenconsoled aren't doing this, then they ought to.)
> > 
> >
> Patch is attached.

Applied, thanks.

Ewan.