Hi,

QEMU (the system emulator) and the storage daemon (QSD) write their PID
to the given file when you specify --pidfile.  They keep the path around
and register exit handlers (QEMU uses an exit notifier, QSD an atexit()
function) to unlink this file when the process terminates.  These
handlers unlink precisely the path that the user has specified via
--pidfile, so if it was a relative path and the process has at any point
changed its working directory, the path no longer points to the PID
file, and so the unlink() will fail (or worse).

When using --daemonize, the process will always change its working
directory to /, so this problem basically always appears when using
--daemonize and --pidfile in conjunction.

(It gets even worse with QEMU\ufffd\ufffd\ufffds --chroot, but I\ufffd\ufffd\ufffdm not sure whether
there\ufffd\ufffd\ufffds any trivial fix for that (whether chroot is used or not is
confined to os-posix.c, so this would need to be externally visible; and
I guess the plain would be to skip the unlink() in that case?), so I\ufffd\ufffd\ufffdd
rather just skip that for now... :/)

We can fix the problem by running realpath() once the PID file has been
created, so we get an absolute path that we can unlink in the exit
handler.  This is done here.

(Another way to fix this might be to open the directory the PID file is
in, keep the FD around, and use unlinkat() in the exit handler.  I
couldn\ufffd\ufffd\ufffdt see any real benefit for this, though, so I didn\ufffd\ufffd\ufffdt go that
route.  It might be beneficial for the --chroot case, but then again,
precisely in that case we probably don\ufffd\ufffd\ufffdt want to keep random directory
FDs around.)


Hanna Reitz (3):
  qsd: Unlink absolute PID file path
  vl: Conditionally register PID file unlink notifier
  vl: Unlink absolute PID file path

 softmmu/vl.c                         | 42 +++++++++++++++++++++-------
 storage-daemon/qemu-storage-daemon.c | 11 +++++++-
 2 files changed, 42 insertions(+), 11 deletions(-)

-- 
2.35.3

Ping

On 09.06.22 14:26, Hanna Reitz wrote:
> Hi,
>
> QEMU (the system emulator) and the storage daemon (QSD) write their PID
> to the given file when you specify --pidfile.  They keep the path around
> and register exit handlers (QEMU uses an exit notifier, QSD an atexit()
> function) to unlink this file when the process terminates.  These
> handlers unlink precisely the path that the user has specified via
> --pidfile, so if it was a relative path and the process has at any point
> changed its working directory, the path no longer points to the PID
> file, and so the unlink() will fail (or worse).
>
> When using --daemonize, the process will always change its working
> directory to /, so this problem basically always appears when using
> --daemonize and --pidfile in conjunction.
>
> (It gets even worse with QEMU’s --chroot, but I’m not sure whether
> there’s any trivial fix for that (whether chroot is used or not is
> confined to os-posix.c, so this would need to be externally visible; and
> I guess the plain would be to skip the unlink() in that case?), so I’d
> rather just skip that for now... :/)
>
> We can fix the problem by running realpath() once the PID file has been
> created, so we get an absolute path that we can unlink in the exit
> handler.  This is done here.
>
> (Another way to fix this might be to open the directory the PID file is
> in, keep the FD around, and use unlinkat() in the exit handler.  I
> couldn’t see any real benefit for this, though, so I didn’t go that
> route.  It might be beneficial for the --chroot case, but then again,
> precisely in that case we probably don’t want to keep random directory
> FDs around.)
>
>
> Hanna Reitz (3):
>    qsd: Unlink absolute PID file path
>    vl: Conditionally register PID file unlink notifier
>    vl: Unlink absolute PID file path
>
>   softmmu/vl.c                         | 42 +++++++++++++++++++++-------
>   storage-daemon/qemu-storage-daemon.c | 11 +++++++-
>   2 files changed, 42 insertions(+), 11 deletions(-)
>