This specific wording seems to be mostly used in the *BSD version of setrlimit
.
Other versions of setrlimit (2)
state
NOTES
A child process created via fork(2) inherits its parent's resource
limits. Resource limits are preserved across execve(2).
Resource limits are per-process attributes that are shared by all of
the threads in a process.
I think this more clearly shows, that a limit of 2 GiB main memory applies to a single process (and its threads). And a child process of this process inherits also a limit of 2 GiB main memory, but this is 2 GiB for its own usage.
In other words, each process would have a limit of 2 GiB, and together they could consume up to 4 GiB of main memory.
On the other side, the man page for cgroups - Linux control groups says
Various subsystems have been implemented,
making it possible to do things such as limiting the amount of CPU
time and memory available to a cgroup, accounting for the CPU time
used by a cgroup, and freezing and resuming execution of the
processes in a cgroup.
So, control groups allow to limit resources over a group of processes.
Limiting the main memory to 2 GiB for a group containing 3 processes, means the main memory used by all 3 processes together may not exceed 2 GiB.
Part of the answer to your question is in my answer that you linked:
if you want to move an already running process to the cgroup, well...
you can't! (...) iptables (...) doesn't match when the cgroup is switched
Well, iptables matches sometimes in this case, like in your cgroup v1 log rule.
Still, iptables seems to always match for the moved process children, as they are immediately created with the right cgroup. So a solution is to start a new shell, move the shell in the cgroup, and run the desired command in this new shell:
sh -c "echo \$$ > /sys/fs/cgroup/unified/test/cgroup.procs && ping 8.8.8.8"
That's indeed what this cgexec replacement script for cgroup v2 does. You may need to edit the script to replace CGBASE
variable value with /sys/fs/cgroup/unified
(get the correct path for your environment with mount -t cgroup2
).
EDIT: Updated novpn.sh to support cgroups v2 with -2
flag.
But is it supposed to work?
I'm a bit surprised that this answer for cgroup v2 actually works given this issue - more in the Notes of this page.
cgroup controllers can only be mounted in one hierarchy (v1 or v2).
$ cat /proc/cgroups
#subsys_name hierarchy num_cgroups enabled
...
net_cls 3 1 1
Which means the net_cls controller is bound to cgroup v1 (otherwise hierarchy would be 0) but iptables still works with cgroup v2 parameter. How I understand it: net_cls network controller is just a cgroup v1 concept that was replaced by cgroup v2 cgroup namespace. So it seems we can use both iptables cgroup v1 and iptables cgroup v2 rules at the same time if the OS supports both cgroup v1 and v2.
Background notes on running services in a network control group:
Except Fedora 31 that switched to cgroup v2 by default, at this time, most distributions still use cgroup v1 by default. cgmanager
is indeed not needed and I recently removed it from the requirements from the answer you linked.
cgmanager
is deprecated and was dropped in bionic, in favor of systemd
own cgroup management implementation. Unfortunately, systemd
maintainers have dropped NetClass option for cgroup v1, because they focus on cgroup v2.
So with cgroup v1, it becomes tricky to run services in a network control group because you need to do all these steps BEFORE the desired service main process (e.g. tor relay, apache executable, whatever) gets executed, without any help from systemd
which is the service launcher:
- Create the cgroup
- Create the iptables rules (same issue for cgroup v2)
- Start (and not move!) the service main process in the proper cgroup, which is tricky for e.g. apache2 as its direct parent is normally systemd (PID=1) and not some random subshell that you can move to the cgroup
This might be possible with the systemd unit service initialization script. Otherwise, cgconfig
could be used, see this question/answer for Ubuntu - but I'd stay away of cgrulesengd
as it may interfere with systemd
.
Best Answer
From the Kernel documentation titled: Network priority cgroup.
excerpt
I believe these priorities work where the higher the number, the higher the precedence. From the
tc
man page:excerpt
So if there are packets for a lower class they have to wait until there aren't any from a higher numbered class.
References