[Pkg-xen-devel] Bug#770456: Bug#770456: Bug#770456: Please start a qemu process in domain 0.

[Ian Campbell]

On Thu, 2014-11-27 at 17:41 +0100, Stefan Bader wrote:
> On 27.11.2014 12:18, Ian Campbell wrote:
> > On Thu, 2014-11-27 at 11:02 +0100, Stefan Bader wrote:
> >> On 21.11.2014 13:50, Ian Campbell wrote:
> >>> Package: xen-utils-common
> >>> Version: 4.4.0-1
> >>> Severity: important
> >>> Tags: patch
> >>>
> >>> Under some circumstances the xl toolstack needs to create a loopback
> >>> mount of a guest disk in dom0 (e.g. in order to run pygrub). Depending
> >>> on the nature of the guest disk (e.g. qcow2 or raw file image based)
> >>> this can require a qemu instance in dom0.
> >>>
> >>> The upstream xencommons starts such a qemu on boot. The following patch
> >>> adds this to the Debian packages init script as well.
> >>>
> >>> Once I have a bug number for this I will add it to debian/changelog and
> >>> push the result to feature/bugNNNN as usual.
> >>>
> >>> Thanks,
> >>> Ian.
> >>>
> >>
> <old path removed>
> 
> >> Not sure this already was handled but the --name argument of qemu_stop_real
> >> seems a copy-and-paste bug.
> > 
> > Yes it is, whoops!
> > 
> >>  Playing with it right now, --exec instead of --name
> >> also works out better since qemu-system-i386 is just about too long.
> > 
> > So it is, so this is probably a good idea.
> > 
> > Will you send an updated patch once you've finished testing?
> > 
> 
> So not sure whether the bug processor can handle attachments but Thunderbird
> tends to mess things up otherwise. Also I yet have to figure out the location of
> the repo to make proper patches (sorry about that).

http://anonscm.debian.org/cgit/pkg-xen/xen.git

> Anyway attaching the diff between the current init script and the updated one.
> There is one thing which I did not include there. That is a work around some
> kernel bug (which should be fixed in Debian by now). Just for here I want to
> avoid stepping into the case where the new package is installed with the broken
> kernel because in that situation the dpkg starts a qemu which cannot attach
> properly and in the end both hang and qemu has to be killed hard(er). All a bit
> ugly. So this is likely nothing you need but just in case:
> 
> (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763831)

Urk. I wonder if this explains some of the bugs about the initscript
hanging we had around earlier.

Anyway, your diff seems to only add some code to xenstored_start, I was
expecting a change to qemu_start -- did you find that code was OK in the
end? Or did you end up switching to --exec?

Thanks,
Ian.

> -Stefan
> 
>  xenstored_start()
>  {
>         log_progress_msg "xenstored"
> +       #
> +       # Work-around kernel regression where short name links of
> +       # /proc/$$/exe get replaced on rename unconditionally. This
> +       # should be fixed in the kernel but hitting a bad kernel is
> +       # fatal with starting qemu in dom0 (dpkg/qemu hangs).
> +       #
> +       if [ -f $XENSTORED_PIDFILE ]; then
> +               XSPID="$(cat $XENSTORED_PIDFILE)"
> +               XSBIN="$(ls -la /proc/$XSPID/exe 2>/dev/null)"
> +               XSBIN="${XSBIN#*-> }"
> +               XSBIN="${XSBIN% (deleted)}"
> +               if [ "$XSBIN" != "" ]; then
> +                       if [ "$(basename $XSBIN)" = "xenstored.dpkg-new" ]; then
> +                               return 1
> +                       fi
> +               fi
> +       fi
>         start-stop-daemon --start --quiet --pidfile "$XENSTORED_PIDFILE" --exec
> "$XENSTORED" --test > /dev/null \
> 
> 
> _______________________________________________
> Pkg-xen-devel mailing list
> Pkg-xen-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel