At the moment, the xendomains init script will only create a lockfile
if when started, it actually does something -- either tries to restore
a previously saved domain as a result of XENDOMAINS_RESTORE, or tries
to create a domain as a result of XENDOMAINS_AUTO.
RedHat-based SYSV init systems try to only call "${SERVICE} shutdown"
on systems which actually have an actively running component; and they
use the existence of /var/lock/subsys/${SERVICE} to determine which
systems are running.
This means that at the moment, on RedHat-based SYSV systems (such as
CentOS 6), if you enable xendomains, and have XENDOMAINS_RESTORE set
to "true", but don't happen to start a VM, then your running VMs will
not be suspended on shutdown.
Since the lockfile doesn't really have any other effect than to
prevent duplicate starting, just create it unconditionally every time
we start the xendomains script.
The other option would have been to touch the lockfile if
XENDOMAINS_RESTORE was true regardless of whether there were any
domains to be restored. But this would mean that if you started with
the xendomains script active but XENDOMAINS_RESTORE set to "false",
and then changed it to "true", then xendomains would still not run the
next time you shut down. This seems to me to violate the principle of
least surprise.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Olaf Hering <olaf@aepfle.de>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Commit c996572 changed the LOCKFILE path from a check between two
hardcoded paths (/var/lock/subsys/ or /var/lock) to using the
XEN_LOCK_DIR variable designated at configure time. Since
XEN_LOCK_DIR doesn't (and shouldn't) have the 'subsys' postfix, this
effectively moves all the lock files by default to /var/lock instead.
Unfortunately, this breaks xendomains on RedHat-based SYSV init
systems. RedHat-based SYSV init systems try to only call "${SERVICE}
shutdown" on systems which actually have an actively running
component; and they use the existence of /var/lock/subsys/${SERVICE}
to determine which systems are running.
Changing XEN_LOCK_DIR to /var/lock/subsys is not suitable, as only
system services like xendomains should create lockfiles there; other
locks (such as the console locks) should be created in /var/lock
instead.
Instead, re-instate the check for the subsys/ subdirectory of the lock
directory in the xendomains script.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Olaf Hering <olaf@aepfle.de>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
When restarting or shutting down dom0 the xendomains script tries to
stop all other domains. Don't do this for the xenstore domain, as it
might survive a dom0 reboot in the future.
The same applies to xl shutdown --all. Here the xenstore domain is
flagged as "never stop".
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Since commit:
"xendomains initscript: test for privcmd char device"
(1367e9e5ba)
due to incorrect negation the xendomains initscript bails out
early when both: "/dev/xen/privcmd" and "/proc/xen/privcmd"
are present in dom0.
Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Helper scripts get installed into XEN_SCRIPT_DIR, but initscripts,
helper scripts and udev rules still refer to the hardcoded location
/etc/xen/scripts/. Update scripts, rules and Makefile to refer to
@XEN_SCRIPT_DIR@ instead.
Update configure.ac to substitute the path in files using
XEN_SCRIPT_DIR. Remove XEN_SCRIPT_DIR from StdGNU.mk and SunOS.mk, its
already in Paths.mk.
Note: In SunOS.mk it refered to PRIVATE_PREFIX, which was introduced by
9f6d07bac9 ("tools: get rid of hardcoded
config dirs").
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
[ ijc -- ran autogen.sh as requested ]