diff options
| author | Toshiki Sonoda <sonoda.toshiki@fujitsu.com> | 2022-06-24 09:29:24 +0900 |
|---|---|---|
| committer | Toshiki Sonoda <sonoda.toshiki@fujitsu.com> | 2022-06-24 09:29:24 +0900 |
| commit | 3619f0be9514cd7a2cbdddc6cfb8bc8b7a94485d (patch) | |
| tree | ca432ac3c301c051a1cb72f84c92383d17076a07 /libpod/container_exec.go | |
| parent | 8e88abda85f7bf44b6857ad5d62c8ef58206fce5 (diff) | |
| download | podman-3619f0be9514cd7a2cbdddc6cfb8bc8b7a94485d.tar.gz podman-3619f0be9514cd7a2cbdddc6cfb8bc8b7a94485d.tar.bz2 podman-3619f0be9514cd7a2cbdddc6cfb8bc8b7a94485d.zip | |
Fix: Prevent OCI runtime directory remain
This bug was introduced in https://github.com/containers/podman/pull/8906.
When we use 'podman rm/restart/stop/kill etc...' command to
the container running with --rm, the OCI runtime directory
remains at /run/<runtime name> (root user) or
/run/user/<user id>/<runtime name> (rootless user).
This bug could cause other bugs.
For example, when we checkpoint the container running with
--rm (podman checkpoint --export) and restore it
(podman restore --import) with crun, error message
"Error: OCI runtime error: crun: container `<container id>`
already exists" is outputted.
This error is caused by an attempt to restore the container with
the same container ID as the remaining OCI runtime's container ID.
Therefore, I fix that the cleanupRuntime() function runs to
remove the OCI runtime directory,
even if the container has already been removed by --rm option.
Signed-off-by: Toshiki Sonoda <sonoda.toshiki@fujitsu.com>
Diffstat (limited to 'libpod/container_exec.go')
0 files changed, 0 insertions, 0 deletions