Stop the container once the last 'podman exec' finishes

[debarshiray]

Currently, once a Toolbx container gets started with podman start, as part of the toolbox enter or run commands, it doesn't stop unless the host is shut down or someone explicitly calls podman stop.

This becomes annoying if someone tries to remove the container because commands like podman rm and such don't work without the --force flag, even if all active toolbox enter and run sessions have ended and the user thinks that the container is unused. On smaller machines, it might be undesirable to have these unused entry point processes lying around.

I have devised a solution to this with a system of reference counting based on two advisory file locks. It lets the Toolbx container's entry point keep track of what's happening on the host, and it's able to exit when the last podman exec ends.

I suppose one alternative is to pass a AF_UNIX socket to the container through the NOTIFY_SOCKET environment variable and podman create --sdnotify container, and do the reference counting by sending messages from the host to the entry point before and after each podman exec. One downside is that the reference counting will break if the host process crashes before sending the message to deduct the count after an exec ends. Another downside is that it becomes complicated to call podman start manually outside toolbox enter or run for debugging.

Before I merge it, I am wondering if Podman already has some other facilities for this that I am missing. Does it?

I have seen the original coreos/toolbox script unconditionally invoke podman stop after each podman exec. I suppose the idea is that stop will continue to fail until there are other exec sessions around, and the final stop will actually terminate the container. I vaguely remember that podman stop did work like this long ago. It was probably merely by accident and not guaranteed, because at some point this became more erratic and these days stop terminates the active exec sessions.

Is there any other prior art I should know about?

[Luap99]

podman inspect --format {{.ExecIDs}} <name> that shows a list of all tacked execIDs. If it is empty you can stop it so you don't need your own reference counter.

[debarshiray]

Thanks, @Luap99 . I don't remember if I considered it in the past. Is ExecIDs in podman inspect relatively new?

I suppose it will also need some locking? Otherwise, a concurrent toolbox enter or run that's going through podman start and about to invoke podman exec can race with the clean-up code doing podman inspect and podman stop.

In my solution, I don't have an explicit reference counter. It happens implicitly through the shared and exclusive file locks. Once the entry point is able to acquire the exclusive locks, it knows it's clear to exit.

[Luap99]

AFAICT ExecIDs inspect field should be around for a very long time, pre 1.0 with commit 8b87a17

And yes of course you would need to hold a lock if you have to perform such a check race free. So yeah I guess it would not add anything over your current approach using shared/exclusive file locks.

[debarshiray]

Thanks for looking up that commit!

Yes, it seems that the file locking protocol stays somewhat the same. The main difference is whether the host process issues the podman stop once it can acquire the exclusive locks, or if the entry point process exits when it can acquire the exclusive locks.

Anyway, thanks for the brainstorming. I feel more reassured now. :)

[debarshiray]

I think this discussion can be closed if nobody else comes up with anything else.