[Feature Support] support pid file

[ihexon]

pid files are used to prevent a process from starting multiple vm instances.

For example, through file locks, it can be ensured that only one process can hold the write permission of this file at a time, so adding the logic of obtaining the pid file lock and writing the pid file to the program startup detection logic can prevent repeated startup of multiple copies of the vm instance.

[tylerfanelli]

Thanks for the suggestion @ihexon. What's the use-case here? Can you provide an example of when this pid file would be used?

[nirs]

The pidfile is useful to mange the process. For example minikube creates the pidfile for krunkit when running minkube start so it can terminate it later when running minikue stop.

Creating a pidfile in minikube is racy, since it can be killed before it wrote the pid file. If krunkit creates the pid, there is no race.

The use of a pidile as a lock file is not a good idea since it cannot protect resources such as the unix socket added in #51.

Example: starting 2 krunkit processes with pid file used as a lock, and the same unix socket path:

krunkit --restful-uri unix:///tmp/sock --pidfile ~/vms/1/krunkit.pid
krunkit --restful-uri unix:///tmp/sock --pidfile ~/vms/2/krunkit.pid

The second instance will replace the first instance socket.

For protecting resources like the unix socket we want to add a lock file for the socket, like:

/tmp/sock.lock

In this case the second instance will fail to start since the lockfile is in use.

Using a pidfile as a lock is useful for daemons when there is one instance and one pid file.

I opened a similar issue for vfkit:
crc-org/vfkit#309

[nirs]

crc-org/vfkit#309 was fixed, we should implement this to make it easier for users of vfkit to replace with krunkit.

[jakecorrenti]

crc-org/vfkit#309 was fixed, we should implement this to make it easier for users of vfkit to replace with krunkit.

Already have it on my list of things to start working on today/next week :)

[nirs]

Just adding that we don't have to use the pid as a lock file. It can make sense in some cases but not required. The important part is creating the pidfile before starting the vm.

Currently when we run krunkit in minikube we start the krunkit process and then we wait until the vm ip address is available (using /var/db/dhcpd_leases). If krunkit exit during start because the command line was invalid or libkrun failed, minikube does not detect the termination and wait a minute or so before failing. We can improve this in minikube by checking the child process terminated while waiting for the ip address (vment-helper test script does this).

minikube cannot wait for krunkit since krunkit will exit when the vm terminate, and the minikube process exit once the vm was started and it could connect to the vm and provision Kubernetes.

With a pidfile, minikube can wait until the pidfile is created, and use it as confirmation that the krunkit command was successful. If krunkit exit without creating the pidfile minikube can time out quickly since the pidfile will be created in milliseconds normally.

qemu-nbd has similar behavior - the pidfile is created when the nbd server is ready. This is very useful for programs managing qemu-nbd like vdsm.

krunkit does not need to remove the pidfile, the program managing it will remove the pidfile. But since when krunkit is terminated the pid file becomes stale it can be useful to remove it in atexit handler. If krunkit removes the pidfile it should be the last thing it does.

So a useful implementation would be:

1. Configure the vm
2. Create the pidfile if the option is set
3. Start the vm
4. Wait until the vm terminates
5. (Optional) remove the pidfile

[jakecorrenti]

Just adding that we don't have to use the pid as a lock file. It can make sense in some cases but not required. The important part is creating the pidfile before starting the vm.

Currently when we run krunkit in minikube we start the krunkit process and then we wait until the vm ip address is available (using /var/db/dhcpd_leases). If krunkit exit during start because the command line was invalid or libkrun failed, minikube does not detect the termination and wait a minute or so before failing. We can improve this in minikube by checking the child process terminated while waiting for the ip address (vment-helper test script does this).

minikube cannot wait for krunkit since krunkit will exit when the vm terminate, and the minikube process exit once the vm was started and it could connect to the vm and provision Kubernetes.

With a pidfile, minikube can wait until the pidfile is created, and use it as confirmation that the krunkit command was successful. If krunkit exit without creating the pidfile minikube can time out quickly since the pidfile will be created in milliseconds normally.

qemu-nbd has similar behavior - the pidfile is created when the nbd server is ready. This is very useful for programs managing qemu-nbd like vdsm.

krunkit does not need to remove the pidfile, the program managing it will remove the pidfile. But since when krunkit is terminated the pid file becomes stale it can be useful to remove it in atexit handler. If krunkit removes the pidfile it should be the last thing it does.

So a useful implementation would be:

1. Configure the vm

2. Create the pidfile if the option is set

3. Start the vm

4. Wait until the vm terminates

5. (Optional) remove the pidfile

#71 will at the moment create the pidfile right before we start the VM run krun_start_enter. I still have to write tests and such.