Skip to content

Conversation

jakecorrenti
Copy link
Member

Add a new krun_set_pidfile API to allow the user to specify a path in which to write the current process's ID.

This was inspired by a new option I'm working on for krunkit: containers/krunkit#71. I figured it could be useful for users here as well.

Add a new `krun_set_pidfile` API to allow the user to specify a path in
which to write the current process's ID.

Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
@mtjhrc
Copy link
Collaborator

mtjhrc commented Sep 1, 2025

I am not really a fan of this. Ideally this seems like something the user of this library should be responsible for. But I see your problem with that doing that - we don't have a clear point in the API where we finish building the VM and when when we are starting it. This could be solved more generally by having a function like krun_finalize() before krun_start_enter, but maybe for API v2. Another generic option could be a callback (not that nice IMO)

Also another perspective: krun_start_enter failing is still an arbitrary point - the guest kernel could also fail to start (due to misconfigured kernel arguments perhaphs?, or just some bug in our devices), our init may fail, and also the application in the guest might fail, causing the VM to exit...

@nirs
Copy link
Contributor

nirs commented Sep 1, 2025

I agree that this is better done in the application using libkrun, which is also a better place to remove the pidfile on exit.

The reason to create the pidfile as the last thing before we start the guest is to help the application detect successful start by waiting until the pidfile is created. But once the application detected that the vm was started, it needs to wait until the vm is accessible (e.g. via ssh). During this wait it can detect if libkrun failed after the pidfile was created. So I don't think we gain much by moving the functionality to libkrun.

Cleaning up in libkrun is harder since it should not change process state like ataxia handler. The application using libkrun is a better place to manage process lifecycle.

@mtjhrc
Copy link
Collaborator

mtjhrc commented Sep 1, 2025

For cleanup: #373 is related. Ideally we would have a version of krun_start_enter that instead of exiting the process returns whenever the VM is done running...

@nirs
Copy link
Contributor

nirs commented Sep 1, 2025

I did not that krun_start_enter does not return and call _exit. In this case the user cannot cleanup using atexit handler and this is a good reason to move the funcionallity into libkrun. But fixing clean to call exit() and let the user setup atexit handlers seems like a better approach.

@jakecorrenti
Copy link
Member Author

Closing based on feedback. Thanks all

@jakecorrenti
Copy link
Member Author

I am not really a fan of this. Ideally this seems like something the user of this library should be responsible for. But I see your problem with that doing that - we don't have a clear point in the API where we finish building the VM and when when we are starting it.

Yes, this one one of the reasons I thought it could be helpful here.

This could be solved more generally by having a function like krun_finalize() before krun_start_enter, but maybe for >API v2. Another generic option could be a callback (not that nice IMO)

Also another perspective: krun_start_enter failing is still an arbitrary point - the guest kernel could also fail to start (due to misconfigured kernel arguments perhaphs?, or just some bug in our devices), our init may fail, and also the application in the guest might fail, causing the VM to exit...

Also a fair point

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants