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

2015-08-22 Thread Ian Campbell 
On Mon, 01 Dec 2014 13:02:28 + Ian Campbell i...@debian.org wrote:
 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!

I've rebased the feature branch (feature/bug770456) and included
Stefan's fixes to --exec etc.

I didn't include the start-stop-daemon exec rename workaround. Firstly
because this is fixed in the kernel in Jessie and secondly because if
we are to workaround the buggy kernels then I think we should be doing
that everywhere (i.e. in start-stop-daemon) rather than in each
individual initscript.

Ian.

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

2014-12-01 Thread 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/bug 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-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

2014-12-01 Thread Stefan Bader 
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/bug 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-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel
 
 




signature.asc
Description: OpenPGP digital signature

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

2014-12-01 Thread Ian Campbell 
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.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org