1CGCONFIG.CONF(5) File Formats Manual CGCONFIG.CONF(5)
2
6 cgconfig.conf - libcgroup configuration file
7
9 cgconfig.conf is the configuration file used by libcgroup to define
10 control groups, their parameters and also mount points. The file con‐
11 sists of mount and group sections. These sections can be in arbitrary
12 order. Any line starting with '#' is considered as comment line and is
13 ignored.
14 mount section has the form:
16 mount {
18 <controller> = <path>;
19 ...
20 }
21 controller
24 Name of kernel subsystem. List of subsystems supported by kernel
25 can be found in /proc/cgroups file. Libcgroup merges all sub‐
26 systems mounted to the same directory (see Example 1) and the
27 directory is mounted only once.
28 path The directory path, where group hierarchy associated to given
31 controller, shall be mounted. The directory is created automati‐
32 cally on cgconfig service startup if it does not exist and is
33 deleted on service shutdown.
34 group section has the form:
36 group <name> {
38 [permissions]
39 <controller> {
40 <param name> = <param value>;
41 ...
42 }
43 ...
44 }
45 name Name of the control group. It can contain only characters, which
48 are allowed for directory names. The groups form a tree, i.e. a
49 control group can contain zero or more subgroups. Subgroups can
50 be specified using '/' delimiter.
51 The root control group is always created automatically in all
53 hierarchies and it is the base of the group hierarchy. It can be
54 explicitly specified in cgconfig.conf file by using '.' as group
55 name. This can be used e.g. to set its permissions, as shown in
56 Example 5.
57 When the parent control group of a subgroup is not specified,
59 then it is created automatically.
60 permissions
63 Permissions of the given control group on mounted filesystem.
64 root has always permission to do anything with the control
65 group. Permissions have the following syntax:
66 perm {
67 task {
68 uid = <task user>;
69 gid = <task group>;
70 }
71 admin {
72 uid = <admin name>;
73 gid = <admin group>;
74 }
75 }
76 task user/group Name of the user and the group, which owns
79 tasks file of the control group. I.e. this user
80 and members of this group has write access to
81 the file.
82 admin user/group Name of the user and the group, which owns the
84 rest of control group's files. These users are
85 allowed to set subsystem parameters and create
86 subgroups.
87 Permissions are related only to enclosing control group and are
89 not inherited by subgroups. If there is no perm section in con‐
90 trol group definition, root:root is owner of all files.
91 controller
93 Name of the kernel subsystem. The section can be empty, default
94 kernel parameters will be used in this case. By specifying con‐
95 troller the control group and all its parents are controlled by
96 the specific subsystem. One control group can be controlled by
97 multiple subsystems, even if the subsystems are mounted to dif‐
98 ferent directories. Each control group must be controlled by at
99 least one subsystem, so libcgroup knows, in which hierarchies
100 the control group should be created.
101 The parameters of given controller can be modified in following
103 section enclosed in brackets.
104 param name
106 Name of the file to set. Each controller can have zero or
107 more parameters.
108 param value
110 Value, which should be written to the file when the con‐
111 trol group is created.
112
115 Example 1
116 The configuration file:
117 mount {
119 cpu = /mnt/cgroups/cpu;
120 cpuacct = /mnt/cgroups/cpu;
121 }
122 creates the hierarchy controlled by two subsystems, with no groups
124 inside. It corresponds to following operations:
125 mkdir /mnt/cgroups/cpu
127 mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu
128 Example 2
131 The configuration file:
132 mount {
134 cpu = /mnt/cgroups/cpu;
135 cpuacct = /mnt/cgroups/cpu;
136 }
137 group daemons/www {
139 perm {
140 task {
141 uid = root;
142 gid = webmaster;
143 }
144 admin {
145 uid = root;
146 gid = root;
147 }
148 }
149 cpu {
150 cpu.shares = 1000;
151 }
152 }
153 group daemons/ftp {
155 perm {
156 task {
157 uid = root;
158 gid = ftpmaster;
159 }
160 admin {
161 uid = root;
162 gid = root;
163 }
164 }
165 cpu {
166 cpu.shares = 500;
167 }
168 }
169 creates the hierarchy controlled by two subsystems with one group and
170 two subgroups inside, setting one parameter. It corresponds to follow‐
171 ing operations:
172 mkdir /mnt/cgroups/cpu
174 mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu
175 mkdir /mnt/cgroups/cpu/daemons
177 mkdir /mnt/cgroups/cpu/daemons/www
179 chown root:root /mnt/cgroups/cpu/daemons/www/*
180 chown root:webmaster /mnt/cgroups/cpu/daemons/www/tasks
181 echo 1000 > /mnt/cgroups/cpu/daemons/www/cpu.shares
182 mkdir /mnt/cgroups/cpu/daemons/ftp
184 chown root:root /mnt/cgroups/cpu/daemons/ftp/*
185 chown root:ftpmaster /mnt/cgroups/cpu/daemons/ftp/tasks
186 echo 500 > /mnt/cgroups/cpu/daemons/ftp/cpu.shares
187 The daemons group is created automatically when its first subgroup is
189 created. All its parameters have the default value and only root can
190 access group's files.
191 Since both cpuacct and cpu subsystems are mounted to the same direc‐
193 tory, all groups are implicitly controlled also by cpuacct subsystem,
194 even if there is no cpuacct section in any of the groups.
195 Example 3
198 The configuration file:
199 mount {
202 cpu = /mnt/cgroups/cpu;
203 cpuacct = /mnt/cgroups/cpuacct;
204 }
205 group daemons {
207 cpuacct{
208 }
209 cpu {
210 }
211 }
212 creates two hierarchies and one common group in both of them. It cor‐
213 responds to following operations:
214 mkdir /mnt/cgroups/cpu
216 mkdir /mnt/cgroups/cpuacct
217 mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
218 mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct
219 mkdir /mnt/cgroups/cpu/daemons
221 mkdir /mnt/cgroups/cpuacct/daemons
222 In fact there are two groups created. One in cpuacct hierarchy, the
224 second in cpu hierarchy. These two groups have nothing in common and
225 can contain different subgroups and different tasks.
226 Example 4
229 The configuration file:
230 mount {
233 cpu = /mnt/cgroups/cpu;
234 cpuacct = /mnt/cgroups/cpuacct;
235 }
236 group daemons {
238 cpuacct{
239 }
240 }
241 group daemons/www {
243 cpu {
244 cpu.shares = 1000;
245 }
246 }
247 group daemons/ftp {
249 cpu {
250 cpu.shares = 500;
251 }
252 }
253 creates two hierarchies with few groups inside. One of groups is cre‐
254 ated in both hierarchies.
255 It corresponds to following operations:
257 mkdir /mnt/cgroups/cpu
259 mkdir /mnt/cgroups/cpuacct
260 mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
261 mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct
262 mkdir /mnt/cgroups/cpuacct/daemons
264 mkdir /mnt/cgroups/cpu/daemons
265 mkdir /mnt/cgroups/cpu/daemons/www
266 mkdir /mnt/cgroups/cpu/daemons/ftp
267 Group daemons is created in both hierarchies. In cpuacct hierarchy the
268 group is explicitly mentioned in the configuration file. In cpu hierar‐
269 chy is the group created implicitly when www is created there. These
270 two groups have nothing in common, for example they do not share pro‐
271 cesses and subgroups. Groups www and ftp are created only in cpu hier‐
272 archy and are not controlled by cpuacct subsystem.
273 Example 5
276 The configuration file:
277 mount {
279 cpu = /mnt/cgroups/cpu;
280 cpuacct = /mnt/cgroups/cpu;
281 }
282 group . {
284 perm {
285 task {
286 uid = root;
287 gid = operator;
288 }
289 admin {
290 uid = root;
291 gid = operator;
292 }
293 }
294 cpu {
295 }
296 }
297 group daemons {
299 perm {
300 task {
301 uid = root;
302 gid = daemonmaster;
303 }
304 admin {
305 uid = root;
306 gid = operator;
307 }
308 }
309 cpu {
310 }
311 }
312 creates the hierarchy controlled by two subsystems with one group with
313 some special permissions. It corresponds to following operations:
314 mkdir /mnt/cgroups/cpu
316 mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu
317 chown root:operator /mnt/cgroups/cpu/*
319 chown root:operator /mnt/cgroups/cpu/tasks
320 mkdir /mnt/cgroups/cpu/daemons
322 chown root:operator /mnt/cgroups/cpu/daemons/*
323 chown root:daemonmaster /mnt/cgroups/cpu/daemons/tasks
324 Users, which are members of the operator group are allowed to adminis‐
326 ter the control groups, i.e. create new control groups and can move
327 processes between these groups without having root privileges.
328 Members of daemonmaster group can move processes to daemons control
330 group, but they can not move the process out of the group. Only opera‐
331 tor or root can do that.
332
335 Keep hierarchies separated
336 Having multiple hierarchies is perfectly valid and can be useful in
337 various scenarios. To keeps things clean, do not create one group in
338 multiple hierarchies. Examples 3 and 4 shows, how unreadable and con‐
339 fusing it can be, especially when reading somebody others configuration
340 file.
341 Explicit is better than implicit
344 libcgroup can implicitly create groups which are needed for creation of
345 configured subgroups. This may be useful and save some typing in simple
346 scenarios. When it comes to multiple hierarchies, it's better to
347 explicitly specify all groups and all controllers related to them.
348
351 /etc/cgconfig.conf
352 default libcgroup configuration file
353
356 To be defined...
357
360 Parameter values can be only single string without spaces. Parsing of
361 quoted strings is not implemented.
362 CGCONFIG.CONF(5)