Bug#628912: [Pkg-xen-devel] Bug#628912: Bug#628912: xenconsoled and xenstored stopping unhandled by init script

2011-12-11 Thread Ian Campbell
On Sun, 2011-12-11 at 12:33 +0100, Josip Rodin wrote:
 On Sat, Dec 10, 2011 at 08:03:33PM +0100, Bastian Blank wrote:
  On Thu, Jun 02, 2011 at 01:18:11PM +0200, Josip Rodin wrote:
   When you change XENCONSOLED_ARGS in /etc/default/xend, there's no normal 
   way
   to apply it. Even if you do '/etc/init.d/xend stop', that doesn't stop
   xenconsoled, despite the fact the analogous 'start' action did start it.
   There isn't even a separate init script action to stop it, it has to be
   killed manually. Same goes for xenstored.
  
  There is no way to reliable restart xenstored and xenconsoled. You have
  to reboot.
 
 You mean there's no way to restart them without losing their functionality
 with operating domU machines in the interim? If so, that's fine.

At least in the case of xenstored there is no way to restart since this
will lose the watches which the backends have registered and which will
in turn prevent you from starting any other guests (at least those with
devices) in the future or hotplugging any new devices etc. It will also
break things like graceful shutdown for existing guests.

There has been talk about restartable xenstore upstream but AFAIK no
code has been written nor is anyone actively persueing this at the
moment (obviously we would love it if someone would take this on and
make it work!).

I thought xenconsoled was restartable, the upstream init scripts
certainly do so.

Ian
-- 
Ian Campbell


I can't understand why people are frightened of new ideas.  I'm frightened
of the old ones.
-- John Cage




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



Bug#628912: [Pkg-xen-devel] Bug#628912: Bug#628912: xenconsoled and xenstored stopping unhandled by init script

2011-12-11 Thread Josip Rodin
On Sun, Dec 11, 2011 at 01:12:58PM +, Ian Campbell wrote:
 On Sun, 2011-12-11 at 12:33 +0100, Josip Rodin wrote:
  On Sat, Dec 10, 2011 at 08:03:33PM +0100, Bastian Blank wrote:
   On Thu, Jun 02, 2011 at 01:18:11PM +0200, Josip Rodin wrote:
When you change XENCONSOLED_ARGS in /etc/default/xend, there's no 
normal way
to apply it. Even if you do '/etc/init.d/xend stop', that doesn't stop
xenconsoled, despite the fact the analogous 'start' action did start it.
There isn't even a separate init script action to stop it, it has to be
killed manually. Same goes for xenstored.
   
   There is no way to reliable restart xenstored and xenconsoled. You have
   to reboot.
  
  You mean there's no way to restart them without losing their functionality
  with operating domU machines in the interim? If so, that's fine.
 
 At least in the case of xenstored there is no way to restart since this
 will lose the watches which the backends have registered and which will
 in turn prevent you from starting any other guests (at least those with
 devices) in the future or hotplugging any new devices etc. It will also
 break things like graceful shutdown for existing guests.
 
 There has been talk about restartable xenstore upstream but AFAIK no
 code has been written nor is anyone actively persueing this at the
 moment (obviously we would love it if someone would take this on and
 make it work!).
 
 I thought xenconsoled was restartable, the upstream init scripts
 certainly do so.

I was primarily asking about xenconsoled.

For xenstored, it would certainly be preferable that the stop action checks
whether the active software is such that it can't handle stopping, and that
it then states that explicitly.

-- 
 2. That which causes joy or happiness.



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



Bug#628912: [Pkg-xen-devel] Bug#628912: Bug#628912: xenconsoled and xenstored stopping unhandled by init script

2011-12-11 Thread Ian Campbell
On Sun, 2011-12-11 at 15:10 +0100, Josip Rodin wrote:
 On Sun, Dec 11, 2011 at 01:12:58PM +, Ian Campbell wrote:
  On Sun, 2011-12-11 at 12:33 +0100, Josip Rodin wrote:
   On Sat, Dec 10, 2011 at 08:03:33PM +0100, Bastian Blank wrote:
On Thu, Jun 02, 2011 at 01:18:11PM +0200, Josip Rodin wrote:
 When you change XENCONSOLED_ARGS in /etc/default/xend, there's no 
 normal way
 to apply it. Even if you do '/etc/init.d/xend stop', that doesn't stop
 xenconsoled, despite the fact the analogous 'start' action did start 
 it.
 There isn't even a separate init script action to stop it, it has to 
 be
 killed manually. Same goes for xenstored.

There is no way to reliable restart xenstored and xenconsoled. You have
to reboot.
   
   You mean there's no way to restart them without losing their functionality
   with operating domU machines in the interim? If so, that's fine.
  
  At least in the case of xenstored there is no way to restart since this
  will lose the watches which the backends have registered and which will
  in turn prevent you from starting any other guests (at least those with
  devices) in the future or hotplugging any new devices etc. It will also
  break things like graceful shutdown for existing guests.
  
  There has been talk about restartable xenstore upstream but AFAIK no
  code has been written nor is anyone actively persueing this at the
  moment (obviously we would love it if someone would take this on and
  make it work!).
  
  I thought xenconsoled was restartable, the upstream init scripts
  certainly do so.
 
 I was primarily asking about xenconsoled.
 
 For xenstored, it would certainly be preferable that the stop action checks
 whether the active software is such that it can't handle stopping, and that
 it then states that explicitly.

As it stands today it is never the case that the system can handle
stopping xenstored and still remain a correctly functioning Xen system.
The upstream initscripts unconditionally print:

 WARNING: Not stopping xenstored, as it cannot be restarted

Ian.

-- 
Ian Campbell


Where will it all end?  Probably somewhere near where it all began.




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