All of lore.kernel.org
 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 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.