All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Cc: xen-devel@lists.xenproject.org, Olaf Hering <olaf@aepfle.de>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [PATCH for-4.7 2/2] tools/xendomains: Create lockfile on start unconditionally
Date: Wed, 11 May 2016 15:31:43 +0100	[thread overview]
Message-ID: <20160511143143.GF8063@citrix.com> (raw)
In-Reply-To: <57331551.7060105@citrix.com>

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.dunlap@citrix.com>
> > ---
> > CC: Ian Jackson <ian.jackson@citrix.com>
> > CC: Wei Liu <wei.liu2@citrix.com>
> > CC: Olaf Hering <olaf@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.liu2@citrix.com>

I've queued this series.

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

  reply	other threads:[~2016-05-11 14:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-11 11:14 [PATCH for-4.7 1/2] hotplug: Fix xendomains lock path for RHEL-based systems George Dunlap
2016-05-11 11:14 ` [PATCH for-4.7 2/2] tools/xendomains: Create lockfile on start unconditionally George Dunlap
2016-05-11 11:19   ` George Dunlap
2016-05-11 14:31     ` Wei Liu [this message]
2016-05-11 14:30   ` Wei Liu
2016-05-11 14:38   ` Olaf Hering
2016-05-25 12:57   ` George Dunlap
2016-05-11 14:31 ` [PATCH for-4.7 1/2] hotplug: Fix xendomains lock path for RHEL-based systems Wei Liu
2016-05-11 14:37 ` Olaf Hering
2016-05-25 12:55 ` George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160511143143.GF8063@citrix.com \
    --to=wei.liu2@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=ian.jackson@citrix.com \
    --cc=olaf@aepfle.de \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.