How to set rlimit value to unlimited

[sak0]

opencontainers/runc#1283

runtime should be support type for "RLIMI_INFINITY" ?

[wking]

On Wed, Feb 15, 2017 at 10:17:31PM -0800, cuihaozhi wrote: runtime should be support type for "RLIMI_INFINITY" ?

Yeah, I think the runtime-spec would need to be patched to add this support, if maintainers feel like it should be supported. Previous discussion in the thread starting with [1]. Now that we've landed #648, I expect maintainers would prefer -1 in the JSON to represent RLIM_INFINITY, which would mean making hard/soft signed integer properties. [1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/nfuv8NnOsUg Subject: rlimits Date: Thu, 20 Oct 2016 12:29:17 -0700 Message-ID: <CAJvN1BOB9esrq29_2=rzSquRsRR6Rc10huM6WQoNKNfyFVdufw@mail.gmail.com>

[mrunalp]

RLIM_INFINITY is defined as unsigned long in the kernel. See https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=RLIM_INFINITY so one should be able to set it today.

[hqhq]

Yes kernel defines RLIM_INFINITY as unsigned long, we should use the same value otherwise people won't be able to set values larger than MaxInt64 but smaller than MaxUint64. Regarding set to unlimited, since kernel defines RLIM_INFINITY = ~0UL (some architectures might override it), there is no real unlimited value but setting it as a very large one, so users can always set it by themselves, with the fact that:

uint64(-1) = 18446744073709551615
int64(18446744073709551615) = -1

people can still use -1 to set it as unlimited when update as long as we do this forced conversion in runtime before generating the config. In this case, upper level tools need to define this value as int64, but this limitation should be introduced by upper level tools when they see fit, not by spec.

I'm thinking maybe we should revert #648 , types should always be the same as kernel's, we can only change cfs_quota_us as #499 suggested since the kernel type is signed long long and takes -1 as a real unlimited setting.

@crosbymichael @mrunalp @dqminh @tianon WDYT?

[crosbymichael]

@hqhq ya, that sounds good to me

[mrunalp]

+1

…

On Feb 28, 2017, at 1:54 PM, Michael Crosby ***@***.***> wrote: @hqhq ya, that sounds good to me — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hqhq]

@crosbymichael @mrunalp I pushed #704 to address concerns in my comments, I think we can close this issue and conclude that people can use RLIMI_INFINITY or -1 in upper level tools to denote the value as unlimited, but the generated value for specs should always be uint64. Same applies to *.limit_in_bytes.

[crosbymichael]

ok, i see, its just a weird cast that we have to do for the conversion

[crosbymichael]

We just merged @hqhq pr so this can be closed.