Re: [Xen-devel] c/s 17731 portability issues

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Keir Fraser writes ("Re: [Xen-devel] c/s 17731 portability issues"):
> On 26/5/08 09:07, "Christoph Egger" <Christoph.Egger@xxxxxxx> wrote:
> > BSD ps has no --no-headers  argument.
> > Solaris ps  has no --no-headers argument and -o has a different
> > semantic.
> 
> Then the surrounding logic would need to be fixed up too. I wonder whether
> it is even possible to extract process state from ps in an OS-neutral way?

Certainly running ps in this way is not the right way to do it.

At the time of the qemu-dm crash, surely there are two possible
situations:

 * xend has not been restarted since this domain started.  xend
   is therefore the parent process of qemu-dm and should be able
   to get the process status via wait[pid].

 * xend _has_ been restarted.  In this case reliable failure detection
   is not possible but at the very least `kill(<pid>, 0)' can be used
   to detect whether some process with that pid is still present.  If
   it isn't then we know it has crashed; if it is then perhaps it is
   still running or perhaps the pid has been reused.

If you want a more reliable arrangement, we need a new daemon to be
the parent of qemu-dm, or for qemu-dm to acquire some resource which
the kernel will automatically clean up when it dies.  Obvious
candidates for the latter are a descriptor onto a named pipe or a
fcntl file lock.  Both of the latter should be possible for xend to
set up as qemu-dm's precedessor-in-exec, without needing changes to
qemu-dm itself.

Ian.

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