Improve sandbox cleanup logic

[dobrac]

Improve sandbox cleanup logic to prevent accidental mistakes. The Stop now just stops the sandbox, while Close properly cleans up the resources. You're always required to call Close, you don't need to call Stop. You can also call Wait to listen for the sandbox stop event.

[dobrac]

@cursor review

[dobrac]

Bug: Memory Exit Returns Unset Signal

The NoopMemory.Exit() method returns a new, unset utils.SetOnce instance on each call. This causes callers waiting for the exit signal to block indefinitely, as the distinct SetOnce instances are never set.

packages/orchestrator/internal/sandbox/uffd/noop.go#L51-L54
 

This should be Ok as the noop memory never exits

[ValentaTomas]

Do you need to call stop before close?

[dobrac]

Do you need to call stop before close?

You don't need to now (because it's already handled for you), but you still can if you want to call it sooner

[cursor]

Bug: Sandbox Shutdown Hangs Due to Missing Cancellation

In the ResumeSandbox goroutine, after sbx.Stop() is called, the subsequent Wait() calls on both Firecracker and UFFD processes lack context cancellation. This can cause the goroutine to block indefinitely if one process hasn't fully exited, potentially hanging sandbox shutdowns.

packages/orchestrator/internal/sandbox/sandbox.go#L522-L535

infra/packages/orchestrator/internal/sandbox/sandbox.go

Lines 522 to 535 in 81b2f47

	go func() {
	// Wait for either uffd or fc process to exit
	select {
	case <-fcUffd.Exit().Done():
	case <-fcHandle.Exit.Done():
	}
	err := sbx.Stop(context.WithoutCancel(ctx), tracer)
	uffdWaitErr := fcUffd.Exit().Wait()
	fcErr := fcHandle.Exit.Wait()
	exit.SetError(errors.Join(err, fcErr, uffdWaitErr))
	}()

 

---