search for: xenstored_start

...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 regressi...

...he 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) -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...

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

...uot;$XENCONSOLED_PIDFILE" -- exec "$XENCONSOLED" --test > /dev/null \ || return 1 start-stop-daemon --start --quiet --pidfile "$XENCONSOLED_PIDFILE" -- exec "$XENCONSOLED" -- \ $XENCONSOLED_ARGS --pid-file="$XENCONSOLED_PIDFILE" \ || return 2 } xenstored_start() { log_progress_msg "xenstored" start-stop-daemon --start --quiet --pidfile "$XENSTORED_PIDFILE" -- exec "$XENSTORED" --test > /dev/null \ || return 1 [ -d "$XENSTORED_DIR" ] || mkdir -p "$XENSTORED_DIR" start-stop-daemon --start --quiet -...

...NCONSOLED_PIDFILE" --name xenconsoled RETVAL="$?" [ "$RETVAL" = 2 ] && return 2 start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec "$XENCONSOLED" [ "$?" = 2 ] && return 2 rm -f $PIDFILE return "$RETVAL" } xenstored_start() { log_progress_msg "xenstored" start-stop-daemon --start --quiet --pidfile "$XENSTORED_PIDFILE" --exec "$XENSTORED" --test > /dev/null \ || return 1 [ -d "$XENSTORED_DIR" ] || mkdir -p "$XENSTORED_DIR" [ -x /sbin/restorecon ] && /...

Hans van Kranenburg writes ("[PATCH 08/13] xen init script: rewrite xenstored start logic"): > -XENSTORED="$ROOT"/bin/xenstored > +# In /etc/default/xen, the user can set XENSTORED, which has to be either > +# 'xenstored' or 'oxenstored'. In here, we add the version specific path. > +if [ -n "$XENSTORED" ]; then > +

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 upda...

...NCONSOLED_PIDFILE" --name xenconsoled RETVAL="$?" [ "$RETVAL" = 2 ] && return 2 start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec "$XENCONSOLED" [ "$?" = 2 ] && return 2 rm -f $PIDFILE return "$RETVAL" } xenstored_start() { log_progress_msg "xenstored" start-stop-daemon --start --quiet --pidfile "$XENSTORED_PIDFILE" --exec "$XENSTORED" --test > /dev/null \ || return 1 [ -d "$XENSTORED_DIR" ] || mkdir -p "$XENSTORED_DIR" export XENSTORED_ROOTDIR="$XENS...

...NCONSOLED_PIDFILE" --name xenconsoled RETVAL="$?" [ "$RETVAL" = 2 ] && return 2 start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec "$XENCONSOLED" [ "$?" = 2 ] && return 2 rm -f $PIDFILE return "$RETVAL" } xenstored_start() { log_progress_msg "xenstored" start-stop-daemon --start --quiet --pidfile "$XENSTORED_PIDFILE" --exec "$XENSTORED" --test > /dev/null \ || return 1 [ -d "$XENSTORED_DIR" ] || mkdir -p "$XENSTORED_DIR" [ -x /sbin/restorecon ] && /...

...082e3ad05 100644 --- a/debian/xen-utils-common.xen.init +++ b/debian/xen-utils-common.xen.init @@ -280,7 +280,7 @@ case "$1" in capability_check case "$?" in 0) ;; - *) log_end_msg 255; exit ;; + *) log_end_msg 0; exit ;; # not a dom0, skip the rest esac env_setup xenstored_start -- 2.20.1

...PIDFILE" --name xenconsoled + RETVAL="$?" + [ "$RETVAL" = 2 ] && return 2 + start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec "$QEMU" + [ "$?" = 2 ] && return 2 + rm -f $QEMU_PIDFILE + return "$RETVAL" +} + + xenstored_start() { log_progress_msg "xenstored" @@ -227,6 +285,11 @@ case "$1" in 0|1) ;; *) log_end_msg 1; exit ;; esac + qemu_start + case "$?" in + 0|1) ;; + *) log_end_msg 1; exit ;; + esac log_end_msg 0 ;; stop) @@ -237,6 +300,11 @@ case "$1" in e...

...because it's already running will treat that as a failure. But we don't ever stop xenstored so I think in this case we should probably treat it already being there as a success for `start' ? > The 0|1) which are in several places further on are also confusing me: > > xenstored_start > case "$?" in > 0|1) ;; > *) log_end_msg 1; exit ;; > esac > > I mean, why torture the reader of the code with counter intuitive 1 > values that mean success... I agree. Madness. > > for try_xenstored_var in...

The contents are the wip.testme branch currently on salsa. I combined the wip.initscript and wip.oxenstored into this and added more things today. I think this is pretty gtg and it's smoke tested (in several cases by scping files around instead of doing package build), so it needs a final extra review and test round before putting it in master branch (which I don't want to force push). I

...DFILE" --exec "$QEMU" + RETVAL="$?" + [ "$RETVAL" = 2 ] && return 2 + start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec "$QEMU" + [ "$?" = 2 ] && return 2 + rm -f $QEMU_PIDFILE + return "$RETVAL" +} 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...