mirror of
https://github.com/kata-containers/kata-containers.git
synced 2025-04-29 04:04:45 +00:00
runtime: Start QEMU undaemonized
QEMU has always been started daemonized since the beginning. I could not find any justification for that though, but it certainly introduces a problem : QEMU stops logging errors when started this way, which isn't accaptable from a support standpoint. The QEMU community discourages the use of -daemonize ; mostly because libvirt, QEMU's primary consummer, doesn't use this option and prefers getting errors from QEMU's stderr through a pipe in order to enforce rollover. Now that virtcontainers knows how to start QEMU with a pre- established QMP connection, let's start QEMU without -daemonize. This requires to handle the reaping of QEMU when it terminates. Since cmd.Wait() is blocking, call it from a goroutine. Signed-off-by: Greg Kurz <groug@kaod.org>
This commit is contained in:
parent
bf4e3a618f
commit
a5319c6be6
@ -531,7 +531,7 @@ func (q *qemu) CreateVM(ctx context.Context, id string, network Network, hypervi
|
||||
NoDefaults: true,
|
||||
NoGraphic: true,
|
||||
NoReboot: true,
|
||||
Daemonize: true,
|
||||
Daemonize: false,
|
||||
MemPrealloc: q.config.MemPrealloc,
|
||||
HugePages: q.config.HugePages,
|
||||
IOMMUPlatform: q.config.IOMMUPlatform,
|
||||
@ -951,6 +951,11 @@ func (q *qemu) StartVM(ctx context.Context, timeout int) error {
|
||||
// Wait for it to exit to assume that the QEMU daemon was
|
||||
// actually started.
|
||||
qemuCmd.Wait()
|
||||
} else {
|
||||
// Ensure the QEMU process is reaped after termination
|
||||
go func() {
|
||||
qemuCmd.Wait()
|
||||
}()
|
||||
}
|
||||
|
||||
err = q.waitVM(ctx, qmpConn, timeout)
|
||||
|
Loading…
Reference in New Issue
Block a user