Xen devel - Feb 2008 - [PATH] ioemu: use SIGHUP instead of SIGKILL

The stub domain device model needs to trap the termination signal so as
to actually destroy the stub domain.  SIGKILL can''t be trapped, SIGTERM
is caught by SDL and so may be unnoticed.  SIGHUP can be trapped and is
not caught by SDL (and by default causes a process termination without
core).

Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>

diff -r 2407a61c0d30 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Mon Feb 04 11:04:13 2008 +0000
+++ b/tools/python/xen/xend/image.py	Mon Feb 04 11:04:32 2008 +0000
@@ -329,7 +329,7 @@ class ImageHandler:
             return
         if self.pid:
             try:
-                os.kill(self.pid, signal.SIGKILL)
+                os.kill(self.pid, signal.SIGHUP)
             except OSError, exn:
                 log.exception(exn)
             try:

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

Although this looks potentially reasonable, I''m not sure about the
approach
of SIGHUPing a dom0 ''proxy'' process to kill an hvm stub
domain. How hard
would it be to teach xend just enough about hvm stub domains to have it
directly kill the stub domain at the same time as it kills the normal hvm
domain? I think this would yield a more robust ''xm destroy''
which could
handle a wider range of stub-domain-related hangs/crashes.

 -- Keir

On 4/2/08 11:07, "Samuel Thibault"
<samuel.thibault@eu.citrix.com> wrote:
> The stub domain device model needs to trap the termination signal so as
> to actually destroy the stub domain.  SIGKILL can''t be trapped,
SIGTERM
> is caught by SDL and so may be unnoticed.  SIGHUP can be trapped and is
> not caught by SDL (and by default causes a process termination without
> core).
> 
> Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
> 
> diff -r 2407a61c0d30 tools/python/xen/xend/image.py
> --- a/tools/python/xen/xend/image.py Mon Feb 04 11:04:13 2008 +0000
> +++ b/tools/python/xen/xend/image.py Mon Feb 04 11:04:32 2008 +0000
> @@ -329,7 +329,7 @@ class ImageHandler:
>              return
>          if self.pid:
>              try:
> -                os.kill(self.pid, signal.SIGKILL)
> +                os.kill(self.pid, signal.SIGHUP)
>              except OSError, exn:
>                  log.exception(exn)
>              try:
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

Keir Fraser, le Mon 04 Feb 2008 11:21:02 +0000, a écrit
:
> Although this looks potentially reasonable, I''m not sure about the
approach
> of SIGHUPing a dom0 ''proxy'' process to kill an hvm stub
domain. How hard
> would it be to teach xend just enough about hvm stub domains to have it
> directly kill the stub domain at the same time as it kills the normal hvm
> domain?
It also needs to know that it has to kill the VNC client, etc.

That said, I''m wondering how to transmit the name of the stub domain.
Could the device model for instance write it in xenstore ?

Samuel

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

On 4/2/08 11:26, "Samuel Thibault"
<samuel.thibault@eu.citrix.com> wrote:
> Keir Fraser, le Mon 04 Feb 2008 11:21:02 +0000, a écrit :
>> Although this looks potentially reasonable, I''m not sure about
the approach
>> of SIGHUPing a dom0 ''proxy'' process to kill an hvm
stub domain. How hard
>> would it be to teach xend just enough about hvm stub domains to have it
>> directly kill the stub domain at the same time as it kills the normal
hvm
>> domain?
> 
> It also needs to know that it has to kill the VNC client, etc.
Okay, well let''s go for SIGHUP for now. I am keen that ''xm
destroy'' should
be able to work regardless of any per-guest component failing however. It
really is a crappy user experience if you can get into situations wheere
even xm destroy doesn''t help you. :-)
> That said, I''m wondering how to transmit the name of the stub
domain.
> Could the device model for instance write it in xenstore ?
Well, the choice is yours in that respect. By name do you mean domid? If you
want to be able to trust that value then it needs to be written by the dom0
component that creates the domain.

 -- Keir



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