2017-01-22 14:29 GMT-03:00 Guillermo: > > $ tai64nlocal /run/system-manager/log/current > [...] > 2017-01-21 22:11:17.709678664 system-manager: ERROR: > /sys/fs/cgroup/systemd//cgroup.subtree_control: No such file or > directory > 2017-01-21 22:11:17.709683364 system-manager: ERROR: > /sys/fs/cgroup/systemd//service-manager.slice/cgroup.subtree_control: > No such file or directory
Yeah, writing to cgroup.subtree_control to enable or disable controllers for a hierarchy is v2-only; for cgroups v1, controllers are attached to a hierarchy by passing their names as mount options. And that creates a related issue: system-manager does the C++ equivalent of 'mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd', i.e. the hierarchy rooted in /sys/fs/cgroup/systemd doesn't have cgroup controllers attached, so subdirectories won't have any 'knobs' for set-control-group-knob(1) to act on: $ cat /proc/self/cgroup 1:name=systemd:/service-manager.slice/ttylogin@.service/ttylogin@tty1.service $ ls /sys/fs/cgroup/systemd/service-manager.slice/ttylogin\@.service/ttylogin\@tty1.service cgroup.clone_children cgroup.procs notify_on_release tasks If one mounts another cgroup hierarchy with attached controllers, for example with 'mount -t cgroup -o cpu cgroup /sys/fs/cgroup/cpu', the corresponding knobs won't be in the directory set-control-group-knob expects to find them: $ cat /proc/self/cgroup 2:cpu:/cgroup-in-cpu-hierarchy 1:name=systemd:/service-manager.slice/ttylogin@.service/ttylogin@tty1.service $ ls /sys/fs/cgroup/cpu/cgroup-in-cpu-hierarchy cgroup.clone_children cgroup.procs cpu.shares notify_on_release tasks $ cat /sys/fs/cgroup/cpu/cgroup-in-cpu-hierarchy/cpu.shares 1024 $ set-control-group-knob cpu.shares 2048 set-control-group-knob: FATAL: /service-manager.slice/ttylogin@.service/ttylogin@tty1.service/cpu.shares: No such file or directory One could instead attach controllers to the hierarchy rooted in /sys/fs/cgroup/systemd, for example by mounting it with 'mount -t cgroup -o cpu,name=systemd cgroup /sys/fs/cgroup/systemd' (not with system-manager as process 1), and things would appear to be OK: $ ls /sys/fs/cgroup/systemd/service-manager.slice/ttylogin\@.service/ttylogin\@tty1.service cgroup.clone_children cgroup.procs cpu.shares notify_on_release tasks (i.e. there is now a 'cpu.shares' file) But then set-control-group-knob (and also move-to-control-group I believe) becomes a no-operation because it can't find the cgroups hierarchy; function calls like read_my_control_group(self_cgroup, "name=systemd", current) in source/set-control-group-knob.cpp and source/move-to-control-group.cpp will return false because /proc/self/cgroup doesn't have the expected format: $ cat /proc/self/cgroup 1:cpu,name=systemd:/service-manager.slice/ttylogin@.service/ttylogin@tty1.service (The text between the colons now also contains the cgroup controller name, not just the 'name=systemd' part) $ set-control-group-knob cpu.shares 2048 $ cat /sys/fs/cgroup/systemd/service-manager.slice/ttylogin@.service/ttylogin@tty1.service/cpu.shares 1024 $ set-control-group-knob non-existent-knob 2048 (No output, not even a 'No such file or directory' error). G.