summaryrefslogtreecommitdiff
path: root/libpod/boltdb_state_linux.go
diff options
context:
space:
mode:
authorMatthew Heon <matthew.heon@pm.me>2019-05-07 21:22:06 -0400
committerMatthew Heon <matthew.heon@pm.me>2019-05-07 21:28:22 -0400
commitf5938be1f758abf71f3d91fcb82240220ecfad91 (patch)
tree0392ff8a9a61303ba82be53dd6226be69bd0313b /libpod/boltdb_state_linux.go
parentff260f07e2be55c7fbda24b8727686fc55c650a6 (diff)
downloadpodman-f5938be1f758abf71f3d91fcb82240220ecfad91.tar.gz
podman-f5938be1f758abf71f3d91fcb82240220ecfad91.tar.bz2
podman-f5938be1f758abf71f3d91fcb82240220ecfad91.zip
Improve robustness of pod removal
Removing a pod must first removal all containers in the pod. Libpod requires the state to remain consistent at all times, so references to a deleted pod must all be cleansed first. Pods can have many containers in them. We presently iterate through all of them, and if an error occurs trying to clean up and remove any single container, we abort the entire operation (but cannot recover anything already removed - pod removal is not an atomic operation). Because of this, if a removal error occurs partway through, we can end up with a pod in an inconsistent state that is no longer usable. What's worse, if the error is in the infra container, and it's persistent, we get zombie pods - completely unable to be removed. When we saw some of these same issues with containers not in pods, we modified the removal code there to aggressively purge containers from the database, then try to clean up afterwards. Take the same approach here, and make cleanup errors nonfatal. Once we've gone ahead and removed containers, we need to see pod deletion through to the end - we'll log errors but keep going. Also, fix some other small things (most notably, we didn't make events for the containers removed). Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Diffstat (limited to 'libpod/boltdb_state_linux.go')
0 files changed, 0 insertions, 0 deletions