Open haircommander opened 1 year ago
OK, this only happens when systemd cgroup manager is used; when TasksMax
is not set explicitly, the value is derived from the parent.
OK, I think the spec is not really written well in this part.
The current doc (since https://github.com/opencontainers/runtime-spec/commit/488f174) says is "default is no limit". Here "default" means the default Go value (of 0), and "no limit" can be interpreted as "do not set the limit" (i.e. ignore) or "set the limit to unlimited".
Older version of doc (since https://github.com/opencontainers/runtime-spec/pull/234), which @haircommander refers to, says "A value <= 0 indicates no limit".
There were some other changes in the runtime spec, in particular moving from int64
to *int64
and back.
Overall, this resulted in spec being vague, as a result, runc actually treats 0
as "do not change anything" and crun treats 0
as "no limit".
I think what we should do is
0
in runc.spec
should be a limit of 0, which the kernel treats like a limit of 1 in most cases. Unset in config.json
should mean leave. I looked at this very closely recently, I think the actual spec text is not very unclear but there are issues that make the spec unclear and we need to fix it
IMHO libcontainer API changes are not a big deal. We do not technically support that anyway.
I have a spec PR, I will push when I get back from teaching students.
Description
CRI-O sets its internal pids limit to 0, attempting to "unset" it. I can't find concrete language in the current spec, but seeing https://github.com/opencontainers/runtime-spec/pull/234 implies this should set the pids.max to "max".
However, since the pids limit has been supported in runc, it ignores when PidsLimit is set to 0, which causes values to populate that are unexpected, and potentially are incorrect.
For reference, crun sets the value to max when PidsLimit is set to 0
Steps to reproduce the issue
Describe the results you received and expected
the value seems to not be deterministic, and is not max
What version of runc are you using?
1.1.7, but poking through the code it seems to always have been the case
Host OS information
No response
Host kernel information
No response