xen init/maint scripts: Do nothing if running for wrong Xen package
authorHans van Kranenburg <hans@knorrie.org>
Tue, 5 May 2020 15:50:00 +0000 (17:50 +0200)
committerHans van Kranenburg <hans@knorrie.org>
Tue, 26 May 2020 12:03:18 +0000 (14:03 +0200)
After trying to fix this issue in the init script, we found out that the
problem still happened for systems running with systemd.

The xen-utils-V postinst and prerm have DPKG_MAINTSCRIPT_PACKAGE in
their environment. When calling invoke-rc.d xen <action> under systemd,
the whole circus of translation and compatibility layers is used to
finally end up running the /etc/init.d/xen script again. However, when
ending up there, the DPKG_MAINTSCRIPT_PACKAGE variable is lost.

So, instead of trying to fix this in the init script, avoid calling
invoke-rc.d altogether, when installing or removing for a different
version of Xen than the currently running one.

Since we only call this from two places, and the check is a one liner,
directly put it into the prerm and postinst.

Carefully quote the values on both sides of the comparison. For example,
when removing a xen-utils-V package after rebooting into just Linux
without Xen, the version retrieval helper will print an error like
"ERROR:  Can't find hypervisor information in sysfs!", there will be no
useful output on stdout and it will compare an empty string with the
version of the xen-utils package, resulting in the right action, not
trying to stop or start anything.

To avoid hitting the disappearing xenconsoled scenario, the fix has to
be present in the maintainer scripts of the to be removed *old*
xen-utils-V package. This means users will have to first upgrade to a
package with this fix before upgrading to a different Xen version.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Reviewed-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Closes: #932759 (1/2)
Fixes: cc85504103 "xen init script: Do nothing if running for wrong Xen package"
debian/xen-utils-V.postinst.vsn-in
debian/xen-utils-V.prerm.vsn-in
debian/xen-utils-common.xen.init

index 581327f09ffd06e97e2400b7a0e4802779881b2c..0acebf836bb215c72e16b0eba7cce06ae71c4bef 100644 (file)
@@ -6,7 +6,15 @@ case "$1" in
     configure)
         update-alternatives --remove xen-default /usr/lib/xen-@version@
         if [ -x "/etc/init.d/xen" ]; then
-           invoke-rc.d xen start || exit $?
+            # Only call the init script when this xen-utils-@version@ package
+            # matches the currently running version of Xen. This means, doing
+            # in-place updates (e.g. a security update for same version).
+            #
+            # When installing a xen-utils package for any other Xen version,
+            # leave the running system alone.
+            if [ "$(/usr/lib/xen-common/bin/xen-version)" = "@version@" ]; then
+                invoke-rc.d xen start || exit $?
+            fi
         fi
     ;;
 
index 1aa2cae65fda98638117ca7dc210ab38e30a798d..f1cb4299c30cde1b7bf4a50882d8010e2a49d47b 100644 (file)
@@ -6,7 +6,15 @@ case "$1" in
     remove|upgrade)
         update-alternatives --remove xen-default /usr/lib/xen-@version@
         if [ -x "/etc/init.d/xen" ]; then
-            invoke-rc.d xen stop || exit $?
+            # Only call the init script when removing or while upgrading for
+            # the currently running version of Xen.
+            #
+            # Otherwise, for example after a Xen version upgrade, autoremoval
+            # of an obsolete xen-utils-V package would inadvertently stop
+            # running daemons like xenconsoled.
+            if [ "$(/usr/lib/xen-common/bin/xen-version)" = "@version@" ]; then
+                invoke-rc.d xen stop || exit $?
+            fi
         fi
     ;;
 
index f66ce6b8db18ea9e9d5c3880881d552707def270..05521733494ee8f7db1df5d35cc52ee4e926512c 100644 (file)
@@ -26,33 +26,6 @@ xen)         ;;
 esac
 
 VERSION=$(/usr/lib/xen-common/bin/xen-version)
-
-# The arrangements for the `xen' init script are a bit odd.
-# This script is part of xen-utils-common, of which there is one
-# version installed regardless of the Xen version.
-#
-# But it is called by the prerm and postinsts of xen-utils-VERSION.
-# The idea is that (for example) if xen-utils-VERSION is upgraded, the
-# daemons are restarted.
-#
-# However, this means that this script may be called by the
-# maintscript of a xen-utils-V package for a different V to the
-# running version of Xen (X, say).  Such a xen-utils-V package does
-# not actually want to start or stop its daemons.  Indeed, the version
-# selection machinery would redirect its efforts to the xen-utils-X
-# utilities.  But this is not right: we don't actually want to (for
-# example) stop xenconsoled from xen-utils-X just because some
-# not-currently-relevant xen-utils-V is installed/removed/whatever.
-#
-# So we use DPKG_MAINTSCRIPT_PACKAGE to detect this situation, and
-# turn these extraneous calls into no-ops.
-
-case $DPKG_MAINTSCRIPT_PACKAGE in
-xen-utils-$VERSION)    ;;      # xen-utils-V maintscript, under Xen X=V
-xen-utils-*)           exit 0;; # xen-utils-V maintscript, but under Xen X!=V
-*)                     ;;      # maybe not under dpkg, etc.
-esac
-
 ROOT=$(/usr/lib/xen-common/bin/xen-dir)
 if [ $? -ne 0 ]; then
        log_warning_msg "No compatible Xen utils for Xen $VERSION"