util: keep the pidfile locked

Unfortunately, advisory record locking lose the lock if any fd refering
to the file is closed. There doesn't seem to be a way to preserve the
lock atomically. We could eventually retake the lock if low pidfilefd
is required.

This fixes processes being leaked, as they are not killed in
virPidFileForceCleanupPath() if the lock can be taken. Here also, we may
consider this is not good enough, as a process may leak by simply
closing the pidfilefd.

Fixes commit d146105f1e ("virCommand:
Actually acquire pidfile instead of just writing it")

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This commit is contained in:
Marc-André Lureau 2020-03-25 00:58:00 +01:00 committed by Michal Privoznik
parent 4fe3d5e733
commit be00118d5d
2 changed files with 3 additions and 11 deletions

View File

@ -797,8 +797,7 @@ virExec(virCommandPtr cmd)
virProcessSetMaxCoreSize(0, cmd->maxCore) < 0)
goto fork_error;
if (cmd->pidfile) {
VIR_AUTOCLOSE pidfilefd = -1;
int newpidfilefd = -1;
int pidfilefd = -1;
char c;
pidfilefd = virPidFileAcquirePath(cmd->pidfile, false, getpid());
@ -818,14 +817,7 @@ virExec(virCommandPtr cmd)
VIR_FORCE_CLOSE(pipesync[0]);
VIR_FORCE_CLOSE(pipesync[1]);
/* This is here only to move the pidfilefd
* to the lowest possible number. */
if ((newpidfilefd = dup(pidfilefd)) < 0) {
virReportSystemError(errno, "%s", _("Unable to dup FD"));
goto fork_error;
}
/* newpidfilefd is intentionally leaked. */
/* pidfilefd is intentionally leaked. */
}
if (cmd->hook) {

View File

@ -9,7 +9,7 @@ ENV:USER=test
FD:0
FD:1
FD:2
FD:3
FD:5
DAEMON:yes
CWD:/
UMASK:0022