Newly created cgroup is lost after reboot

Discussion
1

Hi everybody, :wave:

after a while I now wanted to perform some experiments with cgroups.

On Question regarding cpulimit - #24 by Rosika we were discussing some possibilities for restricting cpu-usage.

One of them was cgroups.

What I did was the following:

  • install cgroup-tools on my Debian VM
  • sudo cgcreate -g cpu:/cpulimit
  • sudo cgset -r cpu.shares=512 cpulimit

When issuing the command (example):

sudo cgexec -g cpu:cpulimit dosbox

it works alright but after a system reboot (cold start actually) my newly created cgroup is lost. :slightly_frowning_face:

Surely IĀ“m missing something here. I guess there has to be a way of preserving it. :thinking:

Can anybody help please :question:

Many thanks in advance and many greetings

Rosika :slightly_smiling_face:

1 Like
2

Hi all, :wave:

IĀ“ve been looking around quite a bit and found out (various sources) that it seems to be norrmal behaviour for cgroups (which are created by the user) not to survive reboots.

IĀ“ve also found some hints as how to tackle the problem but havenĀ“t had yet the opportunity to dive into the matter.
IĀ“ll look into it as soon as I can. :wink:

As a workaround I think a simple script involving the above commands should work as well.
So whenever cgexec is needed running the script beforehand should solve the ā€œproblemā€. :slightly_smiling_face:

Yet there was another thing which bothered me quite a bit:

Following the tutorial provided by the two sources

I noticed the cgexec-command was invariably executed as root (with sudo).
Checking the process with top I saw that (in my example dosbox) was accordingly running as root.

ThatĀ“s actually not something I want and after a bit of research I found out that itĀ“s the normal scenario.
A good didcussion can be found here: linux - Does managing cgroups require root access? - Unix & Linux Stack Exchange .

The normal scenario is that you set cgcreate, cgset, cgdelete, cgget, etc. up as root.
Eventually the program/script meant to be restrained from sucking too many resources will be executed as a normal user.
So, setup as root, use and execution as user.

I tried it out and indeed it works. We need the -a and -t parameters with the cgcreate-command.

From man pages:

-a :
defines the name of the user and the group which own the rest of the defined
control groupā€™s files. These users are allowed to set subsystem parameters and
create subgroups. The default value is the same as has the parent cgroup.

-t :
defines the name of the user and the group, which owns tasks file of the defined
control group. I.e. this user and members of this group have write access to the
file. The default value is the same as has the parent cgroup.

So what IĀ“ve done is the following:

sudo cgcreate -t rosika2:rosika2 -a rosika2:rosika2 -g cpu:cpulimited
sudo cgset -r cpu.shares=512 cpulimited

For creation we still need to be root, but we can execute the command as a normal user now :slightly_smiling_face:

cgexec -g cpu:cpulimited dosbox

and top -i proves that dosbox is actually running as non-root:

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND       
1815 rosika2   20   0  472440  75940  13812 R  16,3   7,5   0:02.16 dosbox

Well, together with the script solution mentioned at the beginning I think this could be a good way of working with cgroups . :smiley:

Have a nice Sunday all of you ā€¦
ā€¦ and many greetings from Rosika :slightly_smiling_face: