RSDK-9591 - Add Kill to ManagedProcess #399
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is part one of two PRs that will hopefully help with shutting down all module processes before viam-server exits. Part 2 is here
This is still a draft as I'm looking for thoughts and ideas around making this better.
The idea behind this is for a Kill() call to propagate from the viam-server, and we should not block on anything if possible. The
kill()
s here do not wait for the execed process to complete, and this is intentional - I couldn't find if syscall.Kill waits for completion, so did not use. I wasn't able to find documentation about whetherkill -9
blocks on the signal getting received or if it immediately returns, so opted for.Start()
instead of.Run()
, which means we do notWait()
for the process to return. This does mean that the assumption is that the viam-server ends immediately after and that the system will properly await the processes that we spawned to kill the managed process, otherwise those processes will be zombie'd. I can see changing it so that we do a.Run()
instead, but might mean we would have to do the module process killing in parallel in viam-server.There is a todo to add Kill to the processManager, but a quick glance at how Close works for processManager makes me think that it should be a followup task