It may happen that qemuProcessStop() is called from "qemu-event" thread. But this thread doesn't have any virIdentity set (virIdentity being thread local) and therefore it may be unable to open connection to secondary drivers. It is unable to do so in split daemon scenario, because in there opening a connection is coupled with copying current thread identity onto the connection. Code-wise, virIdentityGetCurrent() returns NULL which in turn makes virGetConnectGeneric() fail. This problem does not occur in monolithic daemon scenario, because no identity copying is done there. Long story short, inability to open secondary driver connection can lead to unwanted results. Therefore, do what qemuProcessReconnectHelper() does - set the new thread identity to be the one of the caller. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2013573 Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> --- src/qemu/qemu_driver.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index a8bf0ecc6f..70b5f37e6b 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -571,6 +571,7 @@ qemuStateInitialize(bool privileged, size_t i; const char *defsecmodel = NULL; g_autofree virSecurityManager **sec_managers = NULL; + g_autoptr(virIdentity) identity = virIdentityGetCurrent(); qemu_driver = g_new0(virQEMUDriver, 1); @@ -915,7 +916,7 @@ qemuStateInitialize(bool privileged, * events that will be dispatched to the worker pool */ qemu_driver->workerPool = virThreadPoolNewFull(0, 1, 0, qemuProcessEventHandler, "qemu-event", - NULL, + identity, qemu_driver); if (!qemu_driver->workerPool) goto error; -- 2.32.0
