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 <[email protected]>
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.
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
