An interface for cgroups manipulation that handles cgroup version details (i.e., differences between v1 and v2) and provides safe usage of the cgroups filesystem mount.
rebar compile
Update or create the cgroup "group1/nested1" with the OS pid 19368, then delete the cgroup path after moving the OS pid back to the root cgroup (executed as root).
# erl -pz ebin
1> application:start(cgroups).
2> OSPid0 = 19368.
3> CGroupPath = "group1/nested1".
4> {ok, CGroups} = cgroups:new().
5> MemoryLimit = case cgroups:version(CGroups) of 1 -> "memory.limit_in_bytes"; 2 -> "memory.high" end.
6> cgroups:update_or_create(CGroupPath,
[OSPid0],
[{MemoryLimit, "10000000"}],
CGroups).
7> cgroups:update("", [OSPid0], [], CGroups).
8> cgroups:delete_recursive(CGroupPath, CGroups).
9> cgroups:destroy(CGroups).
cgroups:update/4
and cgroups:update_or_create/4
Errors:
- Either root execution of beam.smp or
setcap cap_sys_admin=+ep /path/to/beam.smp
before execution is required for most usage of cgroups - A Linux/systemd setup may have the control group setup mode set to
hybrid
due to it being the recommended default for distributions. However, that mode blocks the use of cgroup controllers (the file/sys/fs/cgroup/unified/cgroup.controllers
is empty) because the cgroup controllers can only be mounted in one hierarchy (v1 or v2). If cgroup v1 should be used, the Linux kernel argumentsystemd.legacy_systemd_cgroup_controller=1
can be used. If cgroup v2 should be used, the Linux kernel argumentsystemd.unified_cgroup_hierarchy=1
can be used (with systemd >=v226
and kernel >=4.2
) orcgroup_no_v1=all
can be used (with kernel >=4.6
). - Any non-root use should only use
cgroups:update/4
with more limited controllers (memory, pids, possibly cpu and/or io) and all OS pids added elsewhere as root
Michael Truog (mjtruog at protonmail dot com)
MIT License