fix(store): do not trust PID files left behind by a previous boot

[ekalinin]

Problem

store.ReadPIDFile() decides whether a PID file belongs to a running process by signaling the PID. Within a single boot that is fine: the PID file of a process that has already exited is removed. Across a reboot it is not, because the recorded PID may have been reused by an unrelated process. osutil.ProcessAlive() also treats EPERM as "alive", which makes a false positive likely when the reused PID belongs to a process of another user.

The instance is then reported as Broken, either with <vmtype> driver is running but host agent is not, or by trying to connect to a stale ha.sock. limactl start fails immediately, and a LaunchDaemon with KeepAlive crash-loops it.

This is the root cause of bug 2 of #5087 and of #5075.

Changes

• osutil.BootSessionID() returns an identifier of the current boot: the kern.bootsessionuuid sysctl on macOS, /proc/sys/kernel/random/boot_id on Linux. On other platforms it returns ErrBootSessionNotSupported and nothing changes.
• store.WritePIDFile() writes a PID file and keeps a boot-session.tmp marker in the same directory. ReadPIDFile() ignores a PID file whose marker is from a different boot, and never signals its PID.
• The host agent, the vz driver and the krunkit driver write their PID files through WritePIDFile(). qemu.pid is written by QEMU itself, but the marker is per instance directory, so it is covered too.
• StartWithPaths() checked for ha.pid with os.Stat(), which bypassed all of this; it now uses ReadPIDFile(), like limactl hostagent already did.

The marker is shared by the PID files of a directory, so the ordering matters:

• A writer that finds a marker of a previous boot removes every PID file of the directory before it refreshes the marker. Refreshing the marker must never make a PID file of a previous boot look current.
• A reader checks the boot before it reads the PID, and leaves the removal to the next writer, so that a reader cannot remove a PID file that another process is writing at that very moment.
• The PID file itself is renamed into place, so a reader never sees a partially written one.
• When the boot session ID cannot be determined, the PID file is not written at all: a marker left over from a previous boot would otherwise void a PID file that is current. Only the platforms without support for a boot session ID fall back to the previous behavior.

An instance that was started by an older version of Lima has no marker, and keeps the previous behavior.

The .tmp suffix of the marker is deliberate: it is then already covered by the cleanup in StopForcibly() and by the skip list used when cloning an instance.

Testing

go test ./pkg/store/... covers writing the marker, a PID file from a previous boot (the PID used in the test is alive, and is still reported as gone), the sweep of the PID files of a previous boot, a truncated PID file from a previous boot, a failure to determine the boot session ID on both the read and the write path, instances without a marker, and platforms without support for a boot session ID.

go test ./..., go test -race ./pkg/store/..., make golangci-lint and cross builds for linux and windows are clean.

Assisted-by: Claude Code

[AkihiroSuda]

Within a single boot that is fine: the PID file of a process that has already exited is removed. Across a reboot it is not, because the recorded PID may have been reused by an unrelated process.

Even within a single boot, PID can be reused. Less likely though.

[AkihiroSuda]

Thanks