2.8. Moving a Process to a Control Group
Move a process into a cgroup by running the
cgclassify command, for example:
~]# cgclassify -g cpu,memory:group1 1701
The syntax for
cgclassify is:
cgclassify -g subsystems:path_to_cgroup pidlist
where:
- subsystems is a comma‑separated list of subsystems, or
*to launch the process in the hierarchies associated with all available subsystems. Note that if cgroups of the same name exist in multiple hierarchies, the-goption moves the processes in each of those groups. Ensure that the cgroup exists within each of the hierarchies whose subsystems you specify here. - path_to_cgroup is the path to the cgroup within its hierarchies.
- pidlist is a space-separated list of process identifier (PIDs).
If the
-g option is not specified, cgclassify automatically searches the /etc/cgrules.conf file (see Section 2.8.1, “The cgred Service”) and uses the first applicable configuration line. According to this line, cgclassify determines the hierarchies and cgroups to move the process under. Note that for the move to be successful, the destination hierarchies must exist. The subsystems specified in /etc/cgrules.conf also have to be properly configured for the corresponding hierarchy in /etc/cgconfig.conf.
You can also add the
--sticky option before the pid to keep any child processes in the same cgroup. If you do not set this option and the cgred service is running, child processes are allocated to cgroups based on the settings found in /etc/cgrules.conf. However, the parent process remains in the cgroup in which it was first started.
Using
cgclassify, you can move several processes simultaneously. For example, this command moves the processes with PIDs 1701 and 1138 into cgroup group1/:
~]# cgclassify -g cpu,memory:group1 1701 1138
Note that the PIDs to be moved are separated by spaces and that the specified groups should be in different hierarchies.
Alternative method
To move a process into a cgroup directly, write its PID to the
tasks file of the cgroup. For example, to move a process with the PID 1701 into a cgroup at /cgroup/cpu_and_mem/group1/:
~]# echo 1701 > /cgroup/cpu_and_mem/group1/tasks2.8.1. The cgred Service
Cgred is a service (which starts the
cgrulesengd service) that moves tasks into cgroups according to parameters set in the /etc/cgrules.conf file. Entries in the /etc/cgrules.conf file can take one of these two forms:
user subsystems control_group
user:command subsystems control_group
Replace user with a user name or a group name prefixed with the "@" character. Replace subsystems with a comma‑separated list of subsystem names, control_group represents a path to the cgroup, and command stands for a process name or a full command path of a process.
For example:
maria devices /usergroup/staff
This entry specifies that any processes that belong to the user named
maria access the devices subsystem according to the parameters specified in the /usergroup/staff cgroup. To associate particular commands with particular cgroups, add the command parameter, as follows:
maria:ftp devices /usergroup/staff/ftp
The entry now specifies that when the user named
maria uses the ftp command, the process is automatically moved to the /usergroup/staff/ftp cgroup in the hierarchy that contains the devices subsystem. Note, however, that the daemon moves the process to the cgroup only after the appropriate condition is fulfilled. Therefore, the ftp process might run for a short time in the wrong group. Furthermore, if the process quickly spawns children while in the wrong group, these children might not be moved.
Entries in the
/etc/cgrules.conf file can include the following extra notation:
@— indicates a group instead of an individual user. For example,@adminsare all users in theadminsgroup.*— represents "all". For example,*in thesubsystemfield represents all mounted subsystems.%— represents an item that is the same as the item on the line above.
For example, the entries specified in the
/etc/cgrules.conf file can have the following form:
@adminstaff devices /admingroup @labstaff % %
The above configuration ensures that processes owned by the
adminstaff and labstaff access the devices subsystem according to the limits set in the admingroup cgroup.
Rules specified in
/etc/cgrules.conf can be linked to templates configured either in the /etc/cgconfig.conf file or in configuration files stored in the /etc/cgconfig.d/ directory, allowing for flexible cgroup assignment and creation.
For example, specify the following template in
/etc/cgconfig.conf:
template users/%g/%u {
cpuacct{
}
cpu {
cpu.shares = "1000";
}
}
Then use the users/%g/%u template in the third row of a
/etc/cgrules.conf entry, which can look as follows:
peter:ftp cpu users/%g/%u
The
%g and %u variables used above are automatically replaced with group and user name depending on the owner of the ftp process. If the process belongs to peter from the adminstaff group, the above path is translated to users/adminstaff/peter. The cgred service then searches for this directory, and if it does not exist, cgred creates it and assigns the process to users/adminstaff/peter/tasks. Note that template rules apply only to definitions of templates in configuration files, so even if "group users/adminstaff/peter" was defined in /etc/cgconfig.conf, it would be ignored in favor of "template users/%g/%u".
There are several other variables that can be used for specifying cgroup paths in templates:
%u— is replaced with the name of the user who owns the current process. If name resolution fails, UID is used instead.%U— is replaced with the UID of the specified user who owns the current process.%g— is replaced with the name of the user group that owns the current process, or with the GID if name resolution fails.%G— is replaced with the GID of the cgroup that owns the current process.%p— is replaced with the name of the current process. PID is used in case of name resolution failure.%P— is replaced with the PID of the current processes.
