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 :|
next prev 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).