Fix race condition with daemonized jailer in startVMM

When using jailer with Daemonize: true, the jailer parent process exits
immediately after forking the child firecracker process. This caused a
race condition where the SDK's process monitoring goroutine would detect
the parent exit and send to errCh before waitForSocket() could establish
the socket connection, causing startVMM to fail prematurely.

This change modifies the process monitoring logic to treat a clean exit
(status=0) of a daemonized jailer parent as expected behavior rather than
an error condition. The goroutine now returns early in this case, allowing
waitForSocket() and other initialization logic to complete normally.

The actual firecracker child process continues running in daemon mode and
creates the API socket as expected.

Signed-off-by: Adam Thomason <adam.thomason@a17n.co.uk>

Author: adamthomason

machine.go

@@ -588,6 +588,16 @@ func (m *Machine) startVMM(ctx context.Context) error {
 	errCh := make(chan error)
 	go func() {
 		waitErr := m.cmd.Wait()
+
+		// If using daemonized jailer and parent exits cleanly,
+		// this is expected behavior. Don't treat it as an error.
+		// We return immediately and allow subsequent functions
+		// (such as waitForSocket) to send any errors to channels.
+		if m.Cfg.JailerCfg != nil && m.Cfg.JailerCfg.Daemonize && waitErr == nil {
+			m.logger.Debugf("jailer parent exited (expected for daemonized mode)")
+			return
+		}
+
 		if waitErr != nil {
 			m.logger.Warnf("firecracker exited: %s", waitErr.Error())
 		} else {
@@ -606,7 +616,6 @@ func (m *Machine) startVMM(ctx context.Context) error {
 		// second one never ends as it tries to read from empty channel.
 		close(errCh)
 		close(m.cleanupCh)
-
 	}()
 
 	m.setupSignals()