Ian Campbell
2014-Dec-01 11:35 UTC
[Pkg-xen-devel] Bug#770456: Bug#770456: Bug#770456: Please start a qemu process in domain 0.
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
Stefan Bader
2014-Dec-01 12:47 UTC
[Pkg-xen-devel] Bug#770456: Bug#770456: Bug#770456: Please start a qemu process in domain 0.
On 01.12.2014 12:35, Ian Campbell wrote:> 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.At least that was what happened to me first.> > 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?Errm, that part was the addition I inlined. The updated change was the full diff between current init script and your changes with the updated qemu_stop_real. And that might have gone missing in the bug tracker at least. It hopefully has survived in the cc that went directly... hopefully... -Stefan> > 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 > >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20141201/d7f50684/attachment.sig>
Ian Campbell
2014-Dec-01 13:02 UTC
[Pkg-xen-devel] Bug#770456: Bug#770456: Bug#770456: Please start a qemu process in domain 0.
On Mon, 2014-12-01 at 13:47 +0100, Stefan Bader wrote:> > 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? > > Errm, that part was the addition I inlined. The updated change was the full diff > between current init script and your changes with the updated qemu_stop_real. > And that might have gone missing in the bug tracker at least. It hopefully has > survived in the cc that went directly... hopefully...It was even in the copy which went via the BTS, I just missed it, sorry! Ian.