Michal Privoznik d146105f1e 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>		2020-03-24 15:44:23 +01:00
..
command.html.in	virCommand: Actually acquire pidfile instead of just writing it	2020-03-24 15:44:23 +01:00
eventloop.html.in	Use https:// links for most sites	2017-10-16 10:22:34 +01:00
locking.html.in	docs: switch to using HTML5 doctype declaration	2017-08-02 17:00:11 +01:00
rpc.html.in	remote: delete the avahi mDNS support	2019-06-21 12:59:42 +01:00