From 9f599aa151619665028074d6c9f46cb39c44a20f Mon Sep 17 00:00:00 2001 From: Peter Hunt Date: Wed, 3 Aug 2022 13:41:42 -0400 Subject: [PATCH] oci: take opLock for UpdateContainer UpdateContainer requests can come in at any time in a container's lifecycle, even when it's shutting down. In some cases, it can cause a container to get stuck: runc pauses the cgroup on v1 and systemd to prevent systemd from mucking around while the cgroup is being updated. In some cases, CRI-O calls `UpdateContainerStatus` during that time, and gets `paused` state. CRI-O does not expect a container to be paused, so it doesn't know how to handle it. Fix this by taking opLock when updating Signed-off-by: Peter Hunt --- internal/oci/runtime_oci.go | 3 +++ 1 file changed, 3 insertions(+) diff --git a/internal/oci/runtime_oci.go b/internal/oci/runtime_oci.go index 8e94f5f498d..9d0b44c3784 100644 --- a/internal/oci/runtime_oci.go +++ b/internal/oci/runtime_oci.go @@ -699,6 +699,9 @@ func TruncateAndReadFile(ctx context.Context, path string, size int64) ([]byte, // UpdateContainer updates container resources func (r *runtimeOCI) UpdateContainer(ctx context.Context, c *Container, res *rspec.LinuxResources) error { + c.opLock.Lock() + defer c.opLock.Unlock() + if c.Spoofed() { return nil }