All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	qemu-block@nongnu.org, Stefan Weil <sw@weilnetz.de>,
	Fam Zheng <famz@redhat.com>,
	Michael Roth <mdroth@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH 1/3] util: add qemu_write_pidfile()
Date: Mon, 3 Sep 2018 10:55:28 +0100	[thread overview]
Message-ID: <20180903095528.GC3467@redhat.com> (raw)
In-Reply-To: <20180831145314.14736-2-marcandre.lureau@redhat.com>

On Fri, Aug 31, 2018 at 04:53:12PM +0200, Marc-André Lureau wrote:
> There are variants of qemu_create_pidfile() in qemu-pr-helper and
> qemu-ga. Let's have a common implementation in libqemuutil.
> 
> The code is initially based from pr-helper write_pidfile(), with
> various improvements and suggestions from Daniel Berrangé:
> 
>   QEMU will leave the pidfile existing on disk when it exits which
>   initially made me think it avoids the deletion race. The app
>   managing QEMU, however, may well delete the pidfile after it has
>   seen QEMU exit, and even if the app locks the pidfile before
>   deleting it, there is still a race.
> 
>   eg consider the following sequence
> 
>         QEMU 1        libvirtd        QEMU 2
> 
>   1.    lock(pidfile)
> 
>   2.    exit()
> 
>   3.                 open(pidfile)
> 
>   4.                 lock(pidfile)
> 
>   5.                                  open(pidfile)
> 
>   6.                 unlink(pidfile)
> 
>   7.                 close(pidfile)
> 
>   8.                                  lock(pidfile)
> 
>   IOW, at step 8 the new QEMU has successfully acquired the lock, but
>   the pidfile no longer exists on disk because it was deleted after
>   the original QEMU exited.
> 
>   While we could just say no external app should ever delete the
>   pidfile, I don't think that is satisfactory as people don't read
>   docs, and admins don't like stale pidfiles being left around on
>   disk.
> 
>   To make this robust, I think we might want to copy libvirt's
>   approach to pidfile acquisition which runs in a loop and checks that
>   the file on disk /after/ acquiring the lock matches the file that
>   was locked. Then we could in fact safely let QEMU delete its own
>   pidfiles on clean exit..
> 
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  include/qemu/osdep.h  |  3 +-
>  os-posix.c            | 24 ---------------
>  os-win32.c            | 25 ----------------
>  qga/main.c            | 54 +++++++---------------------------
>  scsi/qemu-pr-helper.c | 40 ++++---------------------
>  util/oslib-posix.c    | 68 +++++++++++++++++++++++++++++++++++++++++++
>  util/oslib-win32.c    | 27 +++++++++++++++++
>  vl.c                  |  4 +--
>  8 files changed, 114 insertions(+), 131 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  reply	other threads:[~2018-09-03  9:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31 14:53 [Qemu-devel] [PATCH 0/3] util: add qemu_write_pidfile() Marc-André Lureau
2018-08-31 14:53 ` [Qemu-devel] [PATCH 1/3] " Marc-André Lureau
2018-09-03  9:55   ` Daniel P. Berrangé [this message]
2018-08-31 14:53 ` [Qemu-devel] [PATCH 2/3] util: use fcntl() for qemu_write_pidfile() locking Marc-André Lureau
2018-08-31 14:53 ` [Qemu-devel] [PATCH 3/3] RFC: delete PID file on exit Marc-André Lureau
2018-08-31 16:29   ` Stefan Weil
2018-08-31 16:35     ` Marc-André Lureau
2018-09-11 13:14 ` [Qemu-devel] [PATCH 0/3] util: add qemu_write_pidfile() Paolo Bonzini

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=20180903095528.GC3467@redhat.com \
    --to=berrange@redhat.com \
    --cc=famz@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sw@weilnetz.de \
    /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.