mount section has this form:
mount {
- <controller> = <path>;
...
Libcgroup merges all subsystems mounted to the same directory (see Example 1) and the directory is mounted only once.
If no mount section is specified, no controllers are mounted.
group section has this form:
group <name> {
- [permissions]
<controller> {
- <param name> = <param value>;
...
The root control group is always created automatically in all hierarchies and it is the base of the group hierarchy. It can be explicitly specified in cgconfig.conf by using '.' as group name. This can be used e.g. to set its permissions, as shown in Example 6.
When the parent control group of a subgroup is not specified it is created automatically.
perm {
Permissions are only apply to the enclosing control group and are not inherited by subgroups. If there is no perm section in the control group definition, root:root is the owner of all files and default file permissions are preserved if fperm resp. dperm are not specified.
The parameters of the given controller can be modified in the following section enclosed in brackets.
If no group section is specified, no groups are created.
default section has this form:
default {
- perm {
- task {
- uid = <task user>;
gid = <task group>;
fperm = <file permissions>
}
admin {
- uid = <admin name>;
gid = <admin group>;
dperm = <directory permissions>
fperm = <file permissions>
}
}
}
Content of the perm section has the same form as in group section. The permissions defined here specify owner and permissions of groups and files of all groups, which do not have explicitly specified their permissions in their group section.
template section has the same structure as group section. Template name uses the same templates string as cgrules.conf destination tag (see (cgrules.conf (5)). Template definition is used as a control group definition for rules in cgrules.conf (5) with the same destination name. Templates does not use default section settings.
/etc/cgconfig.d/ directory can be used for additional configuration files. cgrulesengd searches this directory for additional templates.
The configuration file:
mount {
creates the hierarchy controlled by two subsystems with no groups inside. It corresponds to the following operations:
mkdir /mnt/cgroups/cpu mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu
The configuration file:
mount {
mkdir /mnt/cgroups/cpu mount -t cgroup -o cpu,name=scheduler cpu /mnt/cgroups/cpu mount -t cgroup -o none,name=noctrl none /mnt/cgroups/noctrl mkdir /mnt/cgroups/cpu/daemons echo 1000 > /mnt/cgroups/cpu/daemons/www/cpu.shares mkdir /mnt/cgroups/noctrl/tests
The daemons group is created automatically when its first subgroup is created. All its parameters have the default value and only root can access group's files.
Since both cpuacct and cpu subsystems are mounted to the same directory, all groups are implicitly controlled also by cpuacct subsystem, even if there is no cpuacct section in any of the groups.
The configuration file:
mount {
mkdir /mnt/cgroups/cpu mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu mkdir /mnt/cgroups/cpu/daemons mkdir /mnt/cgroups/cpu/daemons/www chown root:root /mnt/cgroups/cpu/daemons/www/* chown root:webmaster /mnt/cgroups/cpu/daemons/www/tasks echo 1000 > /mnt/cgroups/cpu/daemons/www/cpu.shares # + chmod the files so the result looks like: # ls -la /mnt/cgroups/cpu/daemons/www/ # admin.dperm = 755: # drwxr-xr-x. 2 root webmaster 0 Jun 16 11:51 . # # admin.fperm = 744: # --w-------. 1 root webmaster 0 Jun 16 11:51 cgroup.event_control # -r--r--r--. 1 root webmaster 0 Jun 16 11:51 cgroup.procs # -r--r--r--. 1 root webmaster 0 Jun 16 11:51 cpuacct.stat # -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 cpuacct.usage # -r--r--r--. 1 root webmaster 0 Jun 16 11:51 cpuacct.usage_percpu # -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 cpu.rt_period_us # -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 cpu.rt_runtime_us # -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 cpu.shares # -rw-r--r--. 1 root webmaster 0 Jun 16 11:51 notify_on_release # # tasks.fperm = 770 # -rw-rw----. 1 root webmaster 0 Jun 16 11:51 tasks mkdir /mnt/cgroups/cpu/daemons/ftp chown root:root /mnt/cgroups/cpu/daemons/ftp/* chown root:ftpmaster /mnt/cgroups/cpu/daemons/ftp/tasks echo 500 > /mnt/cgroups/cpu/daemons/ftp/cpu.shares # + chmod the files so the result looks like: # ls -la /mnt/cgroups/cpu/daemons/ftp/ # admin.dperm = 755: # drwxr-xr-x. 2 root ftpmaster 0 Jun 16 11:51 . # # admin.fperm = 700: # --w-------. 1 root ftpmaster 0 Jun 16 11:51 cgroup.event_control # -r--------. 1 root ftpmaster 0 Jun 16 11:51 cgroup.procs # -r--------. 1 root ftpmaster 0 Jun 16 11:51 cpuacct.stat # -rw-------. 1 root ftpmaster 0 Jun 16 11:51 cpuacct.usage # -r--------. 1 root ftpmaster 0 Jun 16 11:51 cpuacct.usage_percpu # -rw-------. 1 root ftpmaster 0 Jun 16 11:51 cpu.rt_period_us # -rw-------. 1 root ftpmaster 0 Jun 16 11:51 cpu.rt_runtime_us # -rw-------. 1 root ftpmaster 0 Jun 16 11:51 cpu.shares # -rw-------. 1 root ftpmaster 0 Jun 16 11:51 notify_on_release # # tasks.fperm = 774: # -rw-rw-r--. 1 root ftpmaster 0 Jun 16 11:51 tasks
The daemons group is created automatically when its first subgroup is created. All its parameters have the default value and only root can access the group's files.
Since both cpuacct and cpu subsystems are mounted to the same directory, all groups are implicitly also controlled by the cpuacct subsystem, even if there is no cpuacct section in any of the groups.
The configuration file:
mount {
mkdir /mnt/cgroups/cpu mkdir /mnt/cgroups/cpuacct mount -t cgroup -o cpu cpu /mnt/cgroups/cpu mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct mkdir /mnt/cgroups/cpu/daemons mkdir /mnt/cgroups/cpuacct/daemons
In fact there are two groups created. One in the cpuacct hierarchy, the second in the cpu hierarchy. These two groups have nothing in common and can contain different subgroups and different tasks.
The configuration file:
mount {
It corresponds to the following operations:
mkdir /mnt/cgroups/cpu mkdir /mnt/cgroups/cpuacct mount -t cgroup -o cpu cpu /mnt/cgroups/cpu mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct mkdir /mnt/cgroups/cpuacct/daemons mkdir /mnt/cgroups/cpu/daemons mkdir /mnt/cgroups/cpu/daemons/www echo 1000 > /mnt/cgroups/cpu/daemons/www/cpu.shares mkdir /mnt/cgroups/cpu/daemons/ftp echo 500 > /mnt/cgroups/cpu/daemons/ftp/cpu.shares
The configuration file:
mount {
mkdir /mnt/cgroups/cpu mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu chown root:operator /mnt/cgroups/cpu/* chown root:operator /mnt/cgroups/cpu/tasks mkdir /mnt/cgroups/cpu/daemons chown root:operator /mnt/cgroups/cpu/daemons/* chown root:daemonmaster /mnt/cgroups/cpu/daemons/tasks
Users which are members of the operator group are allowed to administer the control groups, i.e. create new control groups and move processes between these groups without having root privileges.
Members of the daemonmaster group can move processes to the daemons control group, but they can not move the process out of the group. Only the operator or root can do that.
The configuration file:
mount {
The situation is the similar as in Example 4. The only difference is template, which is used if some rule uses "/students/%u" as a destination.
The configuration file:
mount {
This is the same as mount -t cgroup cgroup -o nodev,nosuid,noexec,cpu /mnt/cgroups/cpu It mounts the cpu controller with MS_NODEV, MS_NOSUID and MS_NOEXEC options passed.