Re: [Xen-devel] [PATCH 09/46] tools/hotplug: use XEN_LOCK_DIR instead of hardcoded path

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Mon, Sep 22, 2014 at 1:59 PM, Olaf Hering <olaf@xxxxxxxxx> wrote:
> Use XEN_LOCK_DIR because it is a compiletime setting.
>
> Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> ---
>  tools/hotplug/Linux/xendomains | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/tools/hotplug/Linux/xendomains b/tools/hotplug/Linux/xendomains
> index 0794bb9..c45f132 100644
> --- a/tools/hotplug/Linux/xendomains
> +++ b/tools/hotplug/Linux/xendomains
> @@ -49,12 +49,7 @@ if ! [ -e /proc/xen/privcmd ]; then
>         exit 0
>  fi
>
> -# See docs/misc/distro_mapping.txt
> -if [ -d /var/lock/subsys ]; then
> -       LOCKFILE=/var/lock/subsys/xendomains
> -else
> -       LOCKFILE=/var/lock/xendomains
> -fi
> +LOCKFILE=${XEN_LOCK_DIR}/xendomains

Unfortunately, this is wrong.

On RHEL-based systems, the sysv init system uses
/var/lock/subsys/${service} as an indicator of whether it should call
"${service} stop".  With this change, xendomains will no longer be run
on shutdown on RHEL-based systems, even if it successfully touched*
${LOCKFILE}.

I'm not 100% sure what a proper non-hardcoded fix would be.  Maybe
something like this?

if [ -d ${XEN_LOCK_DIR}/subsys ] ; then
    LOCKFILE=${XEN_LOCK_DIR}/subsys/xendomains
else
    LOCKFILE=${XEN_LOCK_DIR}/xendomains
fi

 -George

(* I say "successfully touched ${LOCKFILE}" because there's apparently
another bug on RHEL-based systems:
- "xendomains start" will only touch ${LOCKFILE} if it actually
started at least one domain
- As noted above, the sysv init will only call "xendomains stop" on
shutdown if the lockfile exists
- So "xendomains start" didn't create any VMs, running VMs won't be
saved when you reboot on RHEL-based systems

This patch just made things consistently never run at all.)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel