Ygtjki

I registred because I didn't manage running cgroups with several tutorials/comments/whatever you find on google. I want to limit the amount of ram a specifix user may use. Internet says "cgroups". My testserver is running Ubuntu 14.04. You can divide the mentioned tutorials in two categories. Directly set limits using echo and use specific config. Neither is working for me.

Setting Limits using echo

cgcreate -g cpu,cpuacct,...:/my_group

finishes without any notices. When I try to run

echo 100M > memory.limit_in_bytes

it just says "not permitted" even when using sudo. I don't even reach any point of limiting another user.

Setting limits using config

I read about two config files. So here are my config files:

cgconfig.conf

mount 
 memory = /cgroup/memory;


group limit_grp 
 memory 
 memory.limit_in_bytes=100M;
 memory.memsw.limit_in_bytes=125M;
 

cgrules.conf

testuser memory limit_grp

When I run

cgconfigparser -l /etc/cgconfig.conf

it mounts to systemd. Now I log on with testuser, run an memory intense task - and it runs without caring about my limit.

I tried rebooting, nothing changed. Even some strange attempts using kernel config didn't work. I'm new to cgroups and didn't expect it to be that complicated. I'd appreciate any suggestions to my topic. Thank you in advance!

The reason you're seeing this behaviour is probably due to the fact that your login session already has a memory limit group associated, and the process is inheriting that, according to systemd configuration.

Check your running process cgroup with:

cat /proc/pid/cgroup

...and you may see something like:

13:name=systemd:/user/0.user/2.session
12:debug:/
11:pids:/
10:net_prio:/user/0.user/2.session
9:perf_event:/user/0.user/2.session
8:net_cls:/user/0.user/2.session
7:freezer:/user/0.user/2.session
6:devices:/user/0.user/2.session
5:memory:/user/0.user/2.session
4:blkio:/user/0.user/2.session
3:cpuacct:/user/0.user/2.session
2:cpu:/
1:cpuset:/

Assuming you don't want this behavior, you can use your custom cgroup with memory controller editing /etc/systemd/logind.conf and removing memory from the Controllers line.

I had a similar problem (on Fedora 29, though): It seemed that my /etc/cgconfig.conf was completely ignored. Running

sudo systemctl enable cgconfig

and rebooting solved the problem.