How to handle checkpointing when started with '--rm'

[adrianreber]

When a container is checkpointed without --export all the checkpoint information about that container is stored in the userdata/ directory.

If a container is started with --rm this directory ('userdata') - and everything else - is removed once the container is stopped or checkpointed. Looking into how to best handle this, it seems that the information what to do with the container on exit is stored in the conmon command-line using --exit-args. This means, that once the container is running there is no way to influence what conmon does with that container on exit.

The problem is now that after podman container checkpoint -l, the checkpoint is written but then everything is deleted. The container can never be restored. If the container is checkpointed with --export this is not a problem, as all the checkpoint information is in the checkpoint archive.

To solve this problem that a checkpointed container started with --rm cannot be restored can either be solved by somehow telling conmon to not delete the container on stop. This, however, seems complicated as it would require to tell conmon to somehow change its --exit-args. There is not really a communication channel between podman and conmon for something like this.

Another way to handle this would be to just block checkpointing if a container is started with --rm. This means that a user needs to know this limitation during container start up.

As I see no easy way to change conmon --exit-args I think the blocking of checkpointing of containers started with --rm is the best (easiest) sollution.

Is there any way to tell conmon to change its --exit-args or should I just block checkpoints of containers started with --rm?

[mheon]

Once Conmon is launched, we can't configure it further - so I don't think we can avoid it removing the container. Having the two conflict seems like the only option.

[rhatdan]

Yes conflict the args.

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[adrianreber]

Will fix this soon.

[rhatdan]

Awesome.

[adrianreber]

Fixed with #4594