qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Fiona Ebner <f.ebner@proxmox.com>
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, hreitz@redhat.com,
	t.lamprecht@proxmox.com, d.csapak@proxmox.com
Subject: Re: [PATCH] vl: change PID file path resolve error to warning
Date: Thu, 27 Oct 2022 13:17:31 +0100	[thread overview]
Message-ID: <Y1p22/LxBASPUTcV@redhat.com> (raw)
In-Reply-To: <20221027101443.118049-1-f.ebner@proxmox.com>

On Thu, Oct 27, 2022 at 12:14:43PM +0200, Fiona Ebner wrote:
> Commit 85c4bf8aa6 ("vl: Unlink absolute PID file path") made it a
> critical error when the PID file path cannot be resolved. Before this
> commit, it was possible to invoke QEMU when the PID file was a file
> created with mkstemp that was already unlinked at the time of the
> invocation. There might be other similar scenarios.
> 
> It should not be a critical error when the PID file unlink notifier
> can't be registered, because the path can't be resolved. Turn it into
> a warning instead.
> 
> Fixes: 85c4bf8aa6 ("vl: Unlink absolute PID file path")
> Reported-by: Dominik Csapak <d.csapak@proxmox.com>
> Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
> ---
> 
> For completeness, here is a reproducer based on our actual invocation
> written in Rust (depends on the "nix" crate). It works fine with QEMU
> 7.0, but not anymore with 7.1.
> 
> use std::fs::File;
> use std::io::Read;
> use std::os::unix::io::{AsRawFd, FromRawFd};
> use std::path::{Path, PathBuf};
> use std::process::Command;
> 
> fn make_tmp_file<P: AsRef<Path>>(path: P) -> (File, PathBuf) {
>     let path = path.as_ref();
> 
>     let mut template = path.to_owned();
>     template.set_extension("tmp_XXXXXX");
>     match nix::unistd::mkstemp(&template) {
>         Ok((fd, path)) => (unsafe { File::from_raw_fd(fd) }, path),
>         Err(err) => panic!("mkstemp {:?} failed: {}", template, err),
>     }
> }
> 
> fn main() -> Result<(), Box<dyn std::error::Error>> {
>     let (mut pidfile, pid_path) = make_tmp_file("/tmp/unlinked.pid.tmp");
>     nix::unistd::unlink(&pid_path)?;
> 
>     let mut qemu_cmd = Command::new("./qemu-system-x86_64");
>     qemu_cmd.args([
>         "-daemonize",
>         "-pidfile",
>         &format!("/dev/fd/{}", pidfile.as_raw_fd()),
>     ]);
> 
>     let res = qemu_cmd.spawn()?.wait_with_output()?;
> 
>     if res.status.success() {
>         let mut pidstr = String::new();
>         pidfile.read_to_string(&mut pidstr)?;
>         println!("got PID {}", pidstr);
>     } else {
>         panic!("QEMU command unsuccessful");
>     }
>     Ok(())
> }
> 
>  softmmu/vl.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index b464da25bc..10dfe773a7 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -2432,10 +2432,9 @@ static void qemu_maybe_daemonize(const char *pid_file)
>  
>          pid_file_realpath = g_malloc0(PATH_MAX);
>          if (!realpath(pid_file, pid_file_realpath)) {
> -            error_report("cannot resolve PID file path: %s: %s",
> -                         pid_file, strerror(errno));
> -            unlink(pid_file);
> -            exit(1);
> +            warn_report("not removing PID file on exit: cannot resolve PID file"
> +                        " path: %s: %s", pid_file, strerror(errno));
> +            return;
>          }

I don't think using warn_report is desirable here.

If the behaviour of passing a pre-unlinked pidfile is considered
valid, then we should allow it without printing a warning every
time an application does this.

warnings are to highlight non-fatal mistakes by applications, and
this is not a mistake, it is intentionally supported behaviour.

With 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 :|



  parent reply	other threads:[~2022-10-27 12:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27 10:14 [PATCH] vl: change PID file path resolve error to warning Fiona Ebner
2022-10-27 12:06 ` Hanna Reitz
2022-10-27 12:17 ` Daniel P. Berrangé [this message]
2022-10-28  7:11   ` Fiona Ebner
2022-10-28  7:26     ` Thomas Lamprecht
2022-10-28  7:54       ` Fiona Ebner

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=Y1p22/LxBASPUTcV@redhat.com \
    --to=berrange@redhat.com \
    --cc=d.csapak@proxmox.com \
    --cc=f.ebner@proxmox.com \
    --cc=hreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=t.lamprecht@proxmox.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).