limactl start does not verify socket_vmnet succeeded, blocks forever on failure
- Dominant language
- Go
- Stars
- 21.9k
- Forks
- 957
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 53
Description
When Lima starts socket_vmnet via `startDaemon()` in `pkg/networks/reconcile/reconcile.go`, it calls `cmd.Start()` and proceeds without checking whether `vmnet_start_interface` succeeded. If socket_vmnet fails (e.g., `VMNET_FAILURE` from vmnet.framework), Lima starts QEMU anyway. With `--foreground`, `limactl start` then blocks indefinitely waiting for SSH to a VM that has no bridged networking.
socket_vmnet exits immediately on `vmnet_start_interface` failure and removes its PID file. Lima could detect this by checking the PID file or process liveness after a short delay.
Additionally, vmnet.framework depends on the `com.apple.NetworkSharing` XPC service. At early boot, this service's Mach port may not be registered yet, causing `vmnet_start_interface` to return `VMNET_FAILURE`. Neither socket_vmnet nor Lima waits for this dependency or retries on failure.
This is one of several issues that make Lima unusable for unattended auto-start via LaunchDaemon. See also #2252.
**Environment:** macOS 15.7.7, Lima 2.1.x (fork), QEMU 11.0.0, Intel x86_64, socket_vmnet bridged mode.
Contributor guide
Research direction
Start in pkg/networks/reconcile/reconcile.go at startDaemon(), and trace how socket_vmnet is started and its PID file is handled. Reproduce a vmnet_start_interface failure on macOS, then verify that limactl detects the failed socket_vmnet process or missing PID file instead of proceeding to QEMU and waiting indefinitely. Done means the failure is reported or retried rather than leaving limactl blocked.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- networking, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100