Add --pidfile CLI option

[bitranox]

Summary

• Add --pidfile <PATH> CLI option that writes the process ID to a file on startup and removes it on clean exit
• Pidfile cleanup happens in openvmm_main() before pal::process::terminate() to ensure removal even though destructors are skipped
• Document the option in the CLI reference guide

Motivation

Long-running openvmm instances need to be managed by external tooling - systemd units, orchestrators, health monitors, and shell scripts. Without a pidfile, callers must resort to fragile pgrep/pidof heuristics that break when multiple VM instances run concurrently with similar command lines.

A pidfile provides a reliable, race-free way to:

• Send signals (SIGTERM, SIGHUP) to a specific VM instance
• Check liveness - verify the process is still running before attempting operations
• Integrate with process supervisors (systemd PIDFile=, monit, supervisord) that depend on pidfiles for lifecycle management
• Script automation - cleanly stop/restart VMs in deployment scripts without ambiguity about which process to target

This is a standard mechanism used by virtually all long-running Unix daemons (nginx, sshd, postgres, qemu) and its absence makes openvmm harder to integrate into production workflows.

Design notes

• No file locking (flock) - standard pidfiles don't require it
• No signal handlers - SIGKILL/crash leaves a stale pidfile, which is normal; consumers should verify the PID is still alive
• Not written for short-lived utility modes (--write-saved-state-proto)
• Parent directories are not created - the caller is expected to ensure the path exists

Test plan

• cargo build --release -p openvmm compiles cleanly
• openvmm --pidfile /tmp/openvmm.pid ... creates file with correct PID
• Pidfile is removed on clean exit
• Missing parent directory produces a clear error message

[smalis-msft]

This seems reasonable to me. I'm not sure if all the tests really provide value, but they seem cheap enough.

[bitranox]

I'm not sure if all the tests really provide value, but they seem cheap enough.

if thats not ok, just request a change. I am new to that repo, so I dont know the common vibes on that.

[chris-oo]

I think a test is useful, as you need a full integration test to make sure it works.

[chris-oo]

should we be gating support for this to just linux/macos? or is this useful on all platforms?

[chris-oo]

is this supported on windows/macos? or should we be limiting it to linux?

[bitranox]

I would say definitely on macos, on windows I dont know if it can be useful. I am more the linux guy.
But since we never know what users want to archieve, we can also have it on windows.
There can be a DOS issue, if the user passes a random (but important) existing filepath as --pidfile, that file will be overwritten. (i guess the same applies for openvmm logfile setting, but I did not check that).

[jstarks]

Four integration tests for a simple thing seems like overkill. Can we incorporate this into the existing ttrpc test?

[bitranox]

Re: test consolidation (jstarks)

Done - consolidated the four standalone pidfile tests into the existing ttrpc integration test. It now adds --pidfile to the ttrpc spawn and verifies both PID content while running and cleanup after exit. The unit test for CLI parsing remains in cli_args.rs.

Re: platform gating (chris-oo)

The implementation uses only std::fs::write, std::fs::remove_file, and std::process::id() - all cross-platform. Pidfiles are primarily a Unix convention (systemd, supervisord, shell scripts), but there's no technical reason to restrict it. Windows process managers and scripts could use it the same way. Since it's opt-in (--pidfile is not passed by default), keeping it available on all platforms seems like the least surprising behavior with zero maintenance cost.

Regarding the file overwrite concern I mentioned earlier - --log-file has the same behavior (overwrites the target path), so this is consistent with existing options.

[bitranox]

thank yall for the review and valuable input.

[smalis-msft]

Thank you for the contributions!