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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel