c/s 17731 portability issues

c/s 17731 portability issues

[Christoph Egger]

Hi!

Changeset 17731 has some portability issues:

BSD ps has no --no-headers  argument.
Solaris ps  has no --no-headers argument and -o has a different
semantic.

For BSD it would be enough to just remove --no-headers.


-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Re: c/s 17731 portability issues

[Keir Fraser]

On 26/5/08 09:07, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

> Hi!
> 
> Changeset 17731 has some portability issues:
> 
> BSD ps has no --no-headers  argument.
> Solaris ps  has no --no-headers argument and -o has a different
> semantic.
> 
> For BSD it would be enough to just remove --no-headers.

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?
The changeset isn't important or useful enough to keep if it's going to
cause portability problems.

 -- Keir

Re: c/s 17731 portability issues

[Ian Jackson]

Keir Fraser writes ("Re: [Xen-devel] c/s 17731 portability issues"):
> On 26/5/08 09:07, "Christoph Egger" <Christoph.Egger@amd.com> 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.

Re: c/s 17731 portability issues

[Ian Jackson]

Ian Jackson writes ("Re: [Xen-devel] c/s 17731 portability issues"):
> If you want a more reliable arrangement, we need [something] 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.

Thinking about it, a named pipe is attractive.  qemu-dm would be
passed the writing end across exec but just keep it and not write
anything to it.  xend would keep the reading end, and when it became
readable could collect the exit status with waitpid (and W_NOHANG).

On restart, xend would attempt to open the fifo again with
O_RDONLY|O_NONBLOCK which would fail EWOUDLBLOCK if qemu-dm was no
longer running.

The implementation is left as an exercise to the reader.  In the
meantime the ps-based checking should be removed.

Ian.