Commit 104385d
committed
config-linux: MAY reject an unfit cgroup
It makes sense for runtime to reject a cgroup which is frozen
(for both new and existing container), otherwise the runtime
command (create/run/exec) may end up being stuck.
It makes sense for runtime to make sure the cgroup for a new container
is empty (i.e. there are no processes it in), and reject it otherwise.
The scenario in which a non-empty cgroup is used for a new container
has multiple problems, for example:
* If two or more containers share the same cgroup, and each container
has its own limits configured, the order of container starts
ultimately determines whose limits will be effectively applied.
* If two or more containers share the same cgroup, and one of containers
is paused/unpaused, all others are paused, too.
* If cgroup.kill is used to forcefully kill the container, it will also
kill other processes that are not part of this container but merely
belong to the same cgroup.
* When a systemd cgroup manager is used, this becomes even worse. Such
as, stop (or even failed start) of any container results in
stopTransientUnit command being sent to systemd, and so (depending
on unit properties) other containers can receive SIGTERM, be killed
after a timeout etc.
* Many other bad scenarios are possible, as the implicit assumption
of 1:1 container:cgroup mapping is broken.
opencontainers/runc#3132
containers/crun#716
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>1 parent 0d6cc58 commit 104385d
1 file changed
Lines changed: 10 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
171 | 171 | | |
172 | 172 | | |
173 | 173 | | |
| 174 | + | |
| 175 | + | |
| 176 | + | |
| 177 | + | |
| 178 | + | |
| 179 | + | |
| 180 | + | |
| 181 | + | |
| 182 | + | |
| 183 | + | |
174 | 184 | | |
175 | 185 | | |
176 | 186 | | |
| |||
0 commit comments