On 1/22/21 12:09 PM, Nikolay Shirokovskiy wrote:
On Fri, Jan 22, 2021 at 12:45 PM Michal Privoznik
<mprivozn(a)redhat.com>
wrote:
> If libvirtd is sent SIGTERM while it is still initializing, it
> may crash. The following scenario was observed (using 'stress' to
> slow down CPU so much that the window where the problem exists is
> bigger):
>
> 1) The main thread is already executing virNetDaemonRun() and is
> in virEventRunDefaultImpl().
> 2) The thread that's supposed to run daemonRunStateInit() is
> spawned already, but daemonRunStateInit() is in its very early
> stage (in the stack trace I see it's executing
> virIdentityGetSystem()).
>
> If SIGTERM (or any other signal that we don't override handler
> for) arrives at this point, the main thread jumps out from
> virEventRunDefaultImpl() and enters virStateShutdownPrepare()
> (via shutdownPrepareCb which was set earlier). This iterates
> through stateShutdownPrepare() callbacks of state drivers and
> reaching qemuStateShutdownPrepare() eventually only to
> dereference qemu_driver. But since thread 2) has not been
> scheduled/not proceeded yet, qemu_driver was not allocated yet.
>
> Solution is simple - just check if qemu_driver is not NULL. But
> doing so only in qemuStateShutdownPrepare() would push the
> problem down to virStateShutdownWait(), well
> qemuStateShutdownWait(). Therefore, duplicate the trick there
> too.
>
I guess this is a partial solution. Initialization may be in a state when
qemu_driver is initialized but qemu_driver->workerPool is still NULL
for example.
Yes.
Maybe we'd better delay shutdown until initialization is finished?
I'm not exactly sure how to achieve that. Do you have a hint? Also, part
of qemu driver state init is autostarting domains (which may take ages).
Michal