Hi friends. I'm one of the developers building Garden, CloudFoundry's container runtime interface. We've been experimentally using containerd as a backend rather than invoking runc directly for container creation, deletion and process management.

Our product supports creation of "sidecar" containers (that share some containery resources with another container, such as cgroups). Our product's implementation of sidecar containers configures the sidecar container to use the same cgroups as the "main" container (we call this the sandbox container).

We've observed that when we:

1. create a container and task
2. create a second container and task, modifying the config.json to share cgroups with the first container
3. destroy the second task (the sidecar)

... The init process in the sandbox container is killed. We've discovered that this is because the containerd server is invoking an unconfigurable runc kill --all on the sidecar container, and because runc considers --all to be "all processes in the container's device cgroup.procs" the init process for the sandbox container is also killed.

The behaviour we would want is to be able to destroy the sidecar container and task without killing the sandbox container's init process.

We can think of two ways to achieve this:

Make the sidecar container use a child cgroup of the sandbox container

We tried this and it worked, kinda. By making the sidecar cgroup a child of the sandbox cgroup rather than sharing one, we broke another of our features - shared memory limits for sidecars and sandboxen. We've gotten around this by setting the use_hierarchy property of the sandbox container manually after container and task creation. We've opened another issue to runtime-spec and will soon to runc (if they like the change) to allow use_hierarchy to be configured via config.json.

allow operators of containerd server to configure the runc kill --all behaviour

We haven't thought about what this might look like, but we thought we'd float the idea here since it would likely be the easier of the two options we thought of, but probably the more controversial one.

Please let us know if you have any thoughts.

• Tom & the Garden contributors