On Wed, May 11, 2016 at 12:19:45PM +0100, George Dunlap wrote: > On 11/05/16 12:14, George Dunlap wrote: > > 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.dun...@citrix.com> > > --- > > CC: Ian Jackson <ian.jack...@citrix.com> > > CC: Wei Liu <wei.l...@citrix.com> > > CC: Olaf Hering <o...@aepfle.de> > > Forgot the release justification. > > This is a bug in xendomains under RHEL sysv init systems -- albeit one > that's been there from the beginning. Creating the lockfile > unconditionally shouldn't cause any problems as far as I can tell. >
I agree. Release-acked-by: Wei Liu <wei.l...@citrix.com> I've queued this series. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel