[Devel] [PATCH RH7] ve/pid: Export kernel.pid_max via ve cgroup
Pavel Tikhomirov
ptikhomirov at virtuozzo.com
Tue Jul 19 05:25:08 PDT 2016
On 07/19/2016 02:46 PM, Cyrill Gorcunov wrote:
> On Tue, Jul 19, 2016 at 02:26:06PM +0300, Pavel Tikhomirov wrote:
>>
>>
>> On 07/19/2016 02:17 PM, Cyrill Gorcunov wrote:
>>> On Tue, Jul 19, 2016 at 02:00:20PM +0300, Pavel Tikhomirov wrote:
>>>> This member represents kernel.pid_max sysctl it is vz-specific but
>>>> lays on pid namespace. To be able to c/r from libvzctl script it is
>>>> better put pid_max in ve cgroup, these way we do not need to enter
>>>> container root pid namespace to get/set these sysctl.
>>>
>>> Wait, kernel.pid_max is not ve-specific (see kernel/sysctl.c in
>>> vanilla kernel). Why do we have to c/r it at all?
>>
>> It is virtualized only in VZ7(see proc_dointvec_pidmax), so in mainstream it
>> is global sysctl unlike our case.
>
> Acked-by: Cyrill Gorcunov <gorcunov at openvz.org>
>
> p.s. I'm not really follow why this feature is needed in container
> at all, i mean the @pid_max virtualization. Presume due to hist. reasons.
If the only reason was(as far as I understood
https://jira.sw.ru/browse/PSBM-6437) to have more pids available on
host(for pid mapping from containers pids) but not in CT, than actually
we can instead make kernel.pid_max readonly in CT and we won't need
c/r-ing it.
Why pid_max is writable in pidns in Upstream is also a riddle - one can
restrict number of processes to 301 from unprivileged user on hole node,
like:
unshare -Upm --fork --mount-proc sysctl -w kernel.pid_max=301
>
--
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.
More information about the Devel
mailing list