3

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!

  • Could you be more specific when you say "mounts to systemd"? You mentioned this was on Ubuntu 14.04, which is not running systemd (but has some related patches). – Mark Stosberg Jun 25 '16 at 22:15
  • It's easy to misunderstand (and hence misapply) redirection with sudo, too. – JdeBP Jun 27 '16 at 14:39
  • I can either add cgroups to /etc/fstab (which will lead to 'failed to parse config') or don't add it at first and pase config. Both fstab and parsing lead to following output in mount: "systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)" – darkspirit510 Jun 27 '16 at 16:31
0

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.

| improve this answer | |
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.