This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [PATCH] Fix bootloader handling when bootloader exits too ea

To: "xen-de >> \"'xen-devel@xxxxxxxxxxxxxxxxxxx'\"" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH] Fix bootloader handling when bootloader exits too early or didn't return any data
From: Michal Novotny <minovotn@xxxxxxxxxx>
Date: Tue, 31 Aug 2010 14:14:32 +0200
Delivery-date: Tue, 31 Aug 2010 05:14:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4
this is the patch to fix empty string handling as the output value of the bootloader string or when the bootloader process exists too early. Without this patch applied the xend process has been stuck indefinitely on the read() function in the bootloader() function since it was waiting for the bootloader process to open the write end of the pipe but if the bootloader process is bogus (e.g. just a user shell script returning with no output and code 0) that doesn't open a FIFO file the read() call was stuck. Therefore this patch is opening the FIFO with O_NDELAY flag to make it non-blocking and it uses pipe() and creates a separate thread for the wait on bootloader process to exit and when bootloader has exited the select() intercepts the end of bootloader process and breaks the loop.

I tried it with the bogus bootloader that just returns with error code 0 and also the bogus bootloader that sleeps for 10 seconds and then returns with error code 0. According to my testing when the bootloader process has finished and the output of the process is empty it fails with "bootloader didn't return any data" message which is the expected behaviour. This patch has also been tested with the various timeout values (incl. no timeout specified) for pyGrub and everything was working fine since it was failing *only* in the case both output from pyGrub was empty and the bootloader process was not running according the pid.

The check for bootloader running is implemented by opening a pipe and passing the write end of the pipe to the new thread that's waiting for the bootloader process to be terminated. When it's terminated it's writing to the write end of the pipe
which is being read by the bootloader() method to terminate the loop.

Testing: The patch has been tested on RHEL-5.5 x86_64 dom0 with latest version of upstream Xen installed (staging) and RHEL-5.4 PV guest both with good and bad bootloader setup. By bad bootloader I mean just the shell script exiting with code 0 and also shell script sleeping for 10 seconds and exiting with code 0. All the tests passed successfully when having following Ian's patch applied: libxl+xend: use correct paths for PV console when running bootloader

Signed-off-by: Michal Novotny <minovotn@xxxxxxxxxx>


Michal Novotny<minovotn@xxxxxxxxxx>, RHCE
Virtualization Team (xen userspace), Red Hat

Attachment: fix-bootloader-empty-output-handling.patch
Description: Text Data

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [PATCH] Fix bootloader handling when bootloader exits too early or didn't return any data, Michal Novotny <=