Erlang cgroups interface

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.

    $ 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,
                                [{MemoryLimit, "10000000"}],
    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 argument
  `systemd.legacy_systemd_cgroup_controller=1` can be used.
  If cgroup v2 should be used, the Linux kernel argument
  `systemd.unified_cgroup_hierarchy=1` can be used
  (with systemd >= `v226` and kernel >= `4.2`) or
  `cgroup_no_v1=all` can be used (with kernel >= `4.6`).


Michael Truog (mjtruog at protonmail dot com)


MIT License