| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] c/s 17731 portability issues
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
|
|
|
| |
|
Home