]> xenbits.xensource.com Git - libvirt.git/commit
virCommand: Actually acquire pidfile instead of just writing it
authorMichal Privoznik <mprivozn@redhat.com>
Fri, 13 Mar 2020 12:12:49 +0000 (13:12 +0100)
committerMichal Privoznik <mprivozn@redhat.com>
Tue, 24 Mar 2020 14:44:23 +0000 (15:44 +0100)
commitd146105f1e4a9e0ab179f0b78c070ea38b9d5334
treea82194e7b2b020e789dd7d20ce7c2909a7bb6b1e
parent8b907dd3098f9bb21396309339e133053f089909
virCommand: Actually acquire pidfile instead of just writing it

Our virCommand module allows us to set a pidfile for commands we
want to spawn. The caller constructs the string of pidfile path
and then uses virCommandSetPidFile() to tell the module to write
the pidfile once the command is ran. This usually works, but has
two flaws:

1) the child process does not hold the pidfile open & locked.
Therefore, the caller (or anybody else) can't use our fancy
virPidFileForceCleanupPath() function to kill the command
afterwards. Also, for everybody else on the system it's
needlessly harder to check if the pid from the pidfile is still
alive or not.

2) if the caller ever makes a mistake and passes the same pidfile
path for two different commands, the start of the second command
will overwrite the pidfile even though the first command might
still be running.

NOTE that this temporarily renders some command spawning
unusable, specifically those code patterns where both
virCommandSetPidFile() is used together with instructing spawned
command to acquire pidfile itself. Fortunately, there is only one
occurrence of such pattern and it is in
qemuProcessStartManagedPRDaemon(). This is fixed in next commit.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
docs/internals/command.html.in
src/util/vircommand.c
tests/commanddata/test4.log