Limiting users ram with cgroups not working (for me)
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!
ubuntu systemd limit ram cgroups
add a comment |
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!
ubuntu systemd limit ram cgroups
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 withsudo
, 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
add a comment |
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!
ubuntu systemd limit ram cgroups
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!
ubuntu systemd limit ram cgroups
ubuntu systemd limit ram cgroups
asked Jun 25 '16 at 17:47
darkspirit510darkspirit510
163
163
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 withsudo
, 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
add a comment |
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 withsudo
, 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
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
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
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
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
add a comment |
2 Answers
2
active
oldest
votes
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.
add a comment |
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.
New contributor
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f292097%2flimiting-users-ram-with-cgroups-not-working-for-me%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
add a comment |
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.
add a comment |
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.
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.
edited Jun 12 '17 at 14:46
Kusalananda
131k17250410
131k17250410
answered Jun 12 '17 at 13:56
St0rMSt0rM
1013
1013
add a comment |
add a comment |
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.
New contributor
add a comment |
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.
New contributor
add a comment |
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.
New contributor
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.
New contributor
New contributor
answered 27 mins ago
Samuel GruetterSamuel Gruetter
101
101
New contributor
New contributor
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f292097%2flimiting-users-ram-with-cgroups-not-working-for-me%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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