~ubuntu-branches/ubuntu/precise/libcgroup/precise-proposed

« back to all changes in this revision

Viewing changes to doc/man/cgconfig.conf.5

  • Committer: Bazaar Package Importer
  • Author(s): Dustin Kirkland
  • Date: 2009-08-26 11:29:17 UTC
  • Revision ID: james.westby@ubuntu.com-20090826112917-402ews2uj6v350d2
Tags: upstream-0.34
ImportĀ upstreamĀ versionĀ 0.34

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
.TH CGCONFIG.CONF 5
 
2
.\"***********************************
 
3
.SH NAME
 
4
cgconfig.conf \- libcgroup configuration file
 
5
.\"***********************************
 
6
.SH DESCRIPTION
 
7
.B "cgconfig.conf"
 
8
is the configuration file used by
 
9
.B libcgroup
 
10
to define control groups, their parameters and also mount points.
 
11
The file consists of
 
12
.I mount
 
13
and
 
14
.I group
 
15
sections.
 
16
These sections can be in arbitrary order.
 
17
Any line starting with '#' is considered as comment line and is
 
18
ignored.
 
19
.LP
 
20
.I mount
 
21
section has the form:
 
22
.RS
 
23
.nf
 
24
.ft B
 
25
.sp
 
26
mount {
 
27
.RS
 
28
.ft B
 
29
<controller> = <path>;
 
30
.I "..."
 
31
.RE
 
32
.ft B
 
33
}
 
34
.ft R
 
35
.fi
 
36
.RE
 
37
 
 
38
.TP
 
39
.B controller
 
40
Name of kernel subsystem. List of subsystems supported by kernel
 
41
can be found in 
 
42
.I /proc/cgroups
 
43
file.
 
44
.B Libcgroup
 
45
merges all subsystems mounted to the same directory (see
 
46
Example 1) and the directory is mounted only once.
 
47
 
 
48
.TP
 
49
.B path
 
50
The directory path, where group hierarchy associated to given
 
51
controller, shall be mounted. The directory is created
 
52
automatically on cgconfig service startup if it does not exist and
 
53
is deleted on service shutdown.
 
54
.LP
 
55
.I group
 
56
section has the form:
 
57
.RS
 
58
.nf
 
59
.ft B
 
60
.sp
 
61
group <name> {
 
62
.RS
 
63
.ft B
 
64
[permissions]
 
65
<controller> {
 
66
.RS
 
67
.ft B
 
68
<param name> = <param value>;
 
69
.I "..."
 
70
.RE
 
71
.ft B
 
72
}
 
73
.I "..."
 
74
.RE
 
75
.ft B
 
76
}
 
77
.ft R
 
78
.fi
 
79
.RE
 
80
 
 
81
.TP
 
82
.B name
 
83
Name of the control group. It can contain only characters, which are
 
84
allowed for directory names. 
 
85
The groups form a tree, i.e. a control group can contain zero or more
 
86
subgroups. Subgroups can be specified using '/' delimiter. 
 
87
 
 
88
The root control group is always created automatically in all hierarchies
 
89
and it is the base of the group hierarchy. It can be explicitly specified in
 
90
.B cgconfig.conf
 
91
file by using '.' as group name. This can be used e.g. to set its permissions,
 
92
as shown in Example 5.
 
93
 
 
94
When the parent control group of a subgroup is not specified,
 
95
then it is created automatically.
 
96
 
 
97
.TP
 
98
.B permissions
 
99
Permissions of the given control group on mounted filesystem.
 
100
.I root
 
101
has always permission to do anything with the control group.
 
102
Permissions have the following syntax:
 
103
.RS 17
 
104
.ft B
 
105
.nf
 
106
perm {
 
107
.RS
 
108
.ft B
 
109
task {
 
110
.RS
 
111
.ft B
 
112
uid = <task user>;
 
113
gid = <task group>;
 
114
.RE
 
115
}
 
116
admin {
 
117
.RS
 
118
uid = <admin name>;
 
119
gid = <admin group>;
 
120
.RE
 
121
}
 
122
.RE
 
123
}
 
124
.fi
 
125
.RE
 
126
.ft R
 
127
 
 
128
.RS
 
129
.TP 17
 
130
.B "task user/group"
 
131
Name of the user and the group, which owns
 
132
.I tasks
 
133
file of the control group. I.e. this user and members of this
 
134
group has write access to the file.
 
135
.TP 17
 
136
.B "admin user/group"
 
137
Name of the user and the group, which owns the rest of control group's
 
138
files. These users are allowed to set subsystem
 
139
parameters and create subgroups.
 
140
.LP
 
141
Permissions are related only to enclosing control group and are not
 
142
inherited by subgroups. If there is no
 
143
.B perm
 
144
section in control group definition,
 
145
.I root:root
 
146
is owner of all files.
 
147
.RE
 
148
.TP
 
149
.B controller
 
150
Name of the kernel subsystem.
 
151
The section can be
 
152
empty, default kernel parameters will be used in this case. By
 
153
specifying
 
154
.B controller
 
155
the control group and all its parents are controlled by the specific
 
156
subsystem. One control group can be controlled by multiple subsystems,
 
157
even if the subsystems are mounted to different directories. Each
 
158
control group must be controlled by at least one subsystem, so
 
159
.B libcgroup
 
160
knows, in which hierarchies the control group should be created.
 
161
 
 
162
The parameters of given controller can be modified in following section 
 
163
enclosed in brackets.
 
164
.RS
 
165
.TP
 
166
.B param name
 
167
Name of the file to set. Each controller can have zero or more
 
168
parameters.
 
169
.TP
 
170
.B param value
 
171
Value, which should be written to the file when the control group is
 
172
created.
 
173
.RE
 
174
 
 
175
.\"********************************************"
 
176
.SH EXAMPLES
 
177
.LP
 
178
.SS Example 1
 
179
.LP
 
180
The configuration file:
 
181
.LP
 
182
.RS
 
183
.nf
 
184
mount {
 
185
.RS
 
186
cpu = /mnt/cgroups/cpu;
 
187
cpuacct = /mnt/cgroups/cpu;
 
188
.RE
 
189
}
 
190
.fi
 
191
.RE
 
192
 
 
193
creates the hierarchy controlled by two subsystems, with no groups
 
194
inside. It corresponds to following operations:
 
195
.LP
 
196
.RS
 
197
.nf
 
198
mkdir /mnt/cgroups/cpu
 
199
mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu
 
200
.fi
 
201
.RE
 
202
 
 
203
.SS Example 2
 
204
.LP
 
205
The configuration file:
 
206
.LP
 
207
.RS
 
208
.nf
 
209
mount {
 
210
.RS
 
211
cpu = /mnt/cgroups/cpu;
 
212
cpuacct = /mnt/cgroups/cpu;
 
213
.RE
 
214
}
 
215
 
 
216
group daemons/www {
 
217
.RS
 
218
perm {
 
219
.RS
 
220
task {
 
221
.RS
 
222
uid = root;
 
223
gid = webmaster;
 
224
.RE
 
225
}
 
226
admin {
 
227
.RS
 
228
uid = root;
 
229
gid = root;
 
230
.RE
 
231
}
 
232
.RE
 
233
}
 
234
cpu {
 
235
.RS
 
236
cpu.shares = 1000;
 
237
.RE
 
238
}
 
239
.RE
 
240
}
 
241
 
 
242
group daemons/ftp {
 
243
.RS
 
244
perm {
 
245
.RS
 
246
task {
 
247
.RS
 
248
uid = root;
 
249
gid = ftpmaster;
 
250
.RE
 
251
}
 
252
admin {
 
253
.RS
 
254
uid = root;
 
255
gid = root;
 
256
.RE
 
257
}
 
258
.RE
 
259
}
 
260
cpu {
 
261
.RS
 
262
cpu.shares = 500;
 
263
.RE
 
264
}
 
265
.RE
 
266
}
 
267
.RE
 
268
.fi
 
269
creates the hierarchy controlled by two subsystems with one group and
 
270
two subgroups inside, setting one parameter.
 
271
It corresponds to following operations:
 
272
.LP
 
273
.RS
 
274
.nf
 
275
mkdir /mnt/cgroups/cpu
 
276
mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu
 
277
 
 
278
mkdir /mnt/cgroups/cpu/daemons
 
279
 
 
280
mkdir /mnt/cgroups/cpu/daemons/www
 
281
chown root:root /mnt/cgroups/cpu/daemons/www/*
 
282
chown root:webmaster /mnt/cgroups/cpu/daemons/www/tasks
 
283
echo 1000 > /mnt/cgroups/cpu/daemons/www/cpu.shares
 
284
 
 
285
mkdir /mnt/cgroups/cpu/daemons/ftp
 
286
chown root:root /mnt/cgroups/cpu/daemons/ftp/*
 
287
chown root:ftpmaster /mnt/cgroups/cpu/daemons/ftp/tasks
 
288
echo 500 > /mnt/cgroups/cpu/daemons/ftp/cpu.shares
 
289
.fi
 
290
.RE
 
291
 
 
292
The
 
293
.I daemons
 
294
group is created automatically when its first subgroup is
 
295
created. All its parameters have the default value and only root can
 
296
access group's files.
 
297
.LP
 
298
Since both
 
299
.I cpuacct
 
300
and
 
301
.I cpu
 
302
subsystems are mounted to the same directory, all
 
303
groups are implicitly controlled also by
 
304
.I cpuacct
 
305
subsystem, even if there is no
 
306
.I cpuacct
 
307
section in any of the groups.
 
308
.RE
 
309
 
 
310
.SS Example 3
 
311
.LP
 
312
The configuration file:
 
313
 
 
314
.LP
 
315
.RS
 
316
.nf
 
317
mount {
 
318
.RS
 
319
cpu = /mnt/cgroups/cpu;
 
320
cpuacct = /mnt/cgroups/cpuacct;
 
321
.RE
 
322
}
 
323
 
 
324
group daemons {
 
325
.RS
 
326
cpuacct{
 
327
}
 
328
cpu {
 
329
}
 
330
.RE
 
331
}
 
332
.fi
 
333
.RE
 
334
creates two hierarchies and one common group in both of them.
 
335
It corresponds to following operations:
 
336
.LP
 
337
.RS
 
338
.nf
 
339
mkdir /mnt/cgroups/cpu
 
340
mkdir /mnt/cgroups/cpuacct
 
341
mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
 
342
mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct
 
343
 
 
344
mkdir /mnt/cgroups/cpu/daemons
 
345
mkdir /mnt/cgroups/cpuacct/daemons
 
346
.fi
 
347
.RE
 
348
 
 
349
In fact there are two groups created. One in
 
350
.I cpuacct
 
351
hierarchy, the second in
 
352
.I cpu
 
353
hierarchy. These two groups have nothing in common and can
 
354
contain different subgroups and different tasks.
 
355
 
 
356
.SS Example 4
 
357
.LP
 
358
 
 
359
The configuration file:
 
360
 
 
361
.LP
 
362
.RS
 
363
.nf
 
364
mount {
 
365
.RS
 
366
cpu = /mnt/cgroups/cpu;
 
367
cpuacct = /mnt/cgroups/cpuacct;
 
368
.RE
 
369
}
 
370
 
 
371
group daemons {
 
372
.RS
 
373
cpuacct{
 
374
}
 
375
.RE
 
376
}
 
377
 
 
378
group daemons/www {
 
379
.RS
 
380
cpu {
 
381
.RS
 
382
cpu.shares = 1000;
 
383
.RE
 
384
}
 
385
.RE
 
386
}
 
387
 
 
388
group daemons/ftp {
 
389
.RS
 
390
cpu {
 
391
.RS
 
392
cpu.shares = 500;
 
393
.RE
 
394
}
 
395
.RE
 
396
}
 
397
.fi
 
398
.RE
 
399
creates two hierarchies with few groups inside. One of groups
 
400
is created in both hierarchies.
 
401
 
 
402
It corresponds to following operations:
 
403
.LP
 
404
.RS
 
405
.nf
 
406
mkdir /mnt/cgroups/cpu
 
407
mkdir /mnt/cgroups/cpuacct
 
408
mount -t cgroup -o cpu cpu /mnt/cgroups/cpu
 
409
mount -t cgroup -o cpuacct cpuacct /mnt/cgroups/cpuacct
 
410
 
 
411
mkdir /mnt/cgroups/cpuacct/daemons
 
412
mkdir /mnt/cgroups/cpu/daemons
 
413
mkdir /mnt/cgroups/cpu/daemons/www
 
414
mkdir /mnt/cgroups/cpu/daemons/ftp
 
415
.fi
 
416
.RE
 
417
Group
 
418
.I daemons
 
419
is created in both hierarchies. In
 
420
.I cpuacct
 
421
hierarchy the group is explicitly mentioned in the configuration
 
422
file. In 
 
423
.I cpu
 
424
hierarchy is the group created implicitly when
 
425
.I www
 
426
is created there. These two groups have nothing in common, for example
 
427
they do not share processes and subgroups. Groups
 
428
.I www
 
429
and
 
430
.I ftp
 
431
are created only in
 
432
.I cpu
 
433
hierarchy and are not controlled by
 
434
.I cpuacct
 
435
subsystem.
 
436
 
 
437
.SS Example 5
 
438
.LP
 
439
The configuration file:
 
440
.LP
 
441
.RS
 
442
.nf
 
443
mount {
 
444
.RS
 
445
cpu = /mnt/cgroups/cpu;
 
446
cpuacct = /mnt/cgroups/cpu;
 
447
.RE
 
448
}
 
449
 
 
450
group . {
 
451
.RS
 
452
perm {
 
453
.RS
 
454
task {
 
455
.RS
 
456
uid = root;
 
457
gid = operator;
 
458
.RE
 
459
}
 
460
admin {
 
461
.RS
 
462
uid = root;
 
463
gid = operator;
 
464
.RE
 
465
}
 
466
.RE
 
467
}
 
468
cpu {
 
469
}
 
470
.RE
 
471
}
 
472
 
 
473
group daemons {
 
474
.RS
 
475
perm {
 
476
.RS
 
477
task {
 
478
.RS
 
479
uid = root;
 
480
gid = daemonmaster;
 
481
.RE
 
482
}
 
483
admin {
 
484
.RS
 
485
uid = root;
 
486
gid = operator;
 
487
.RE
 
488
}
 
489
.RE
 
490
}
 
491
cpu {
 
492
}
 
493
.RE
 
494
}
 
495
.RE
 
496
.fi
 
497
creates the hierarchy controlled by two subsystems with one group with some
 
498
special permissions.
 
499
It corresponds to following operations:
 
500
.LP
 
501
.RS
 
502
.nf
 
503
mkdir /mnt/cgroups/cpu
 
504
mount -t cgroup -o cpu,cpuacct cpu /mnt/cgroups/cpu
 
505
 
 
506
chown root:operator /mnt/cgroups/cpu/*
 
507
chown root:operator /mnt/cgroups/cpu/tasks
 
508
 
 
509
mkdir /mnt/cgroups/cpu/daemons
 
510
chown root:operator /mnt/cgroups/cpu/daemons/*
 
511
chown root:daemonmaster /mnt/cgroups/cpu/daemons/tasks
 
512
.fi
 
513
.RE
 
514
 
 
515
Users, which are members of the 
 
516
.I operator
 
517
group are allowed to administer the control groups, i.e. create new control
 
518
groups and can move processes between these groups without having root
 
519
privileges.
 
520
 
 
521
Members of
 
522
.I daemonmaster
 
523
group can move processes to
 
524
.I daemons
 
525
control group, but they can not move the process out of the group. Only
 
526
.I operator
 
527
or root can do that.
 
528
 
 
529
.SH RECOMMENDATIONS
 
530
.SS Keep hierarchies separated
 
531
Having multiple hierarchies is perfectly valid and can be useful
 
532
in various scenarios. To keeps things clean, do not
 
533
create one group in multiple hierarchies. Examples 3 and 4 shows,
 
534
how unreadable and confusing it can be, especially when reading
 
535
somebody others configuration file.
 
536
 
 
537
.SS Explicit is better than implicit
 
538
.B libcgroup
 
539
can implicitly create groups which are needed for creation of
 
540
configured subgroups. This may be useful and save some typing in
 
541
simple scenarios. When it comes to multiple hierarchies, it's
 
542
better to explicitly specify all groups and all controllers
 
543
related to them.
 
544
 
 
545
.SH FILES
 
546
.LP
 
547
.PD .1v
 
548
.TP 20
 
549
.B /etc/cgconfig.conf
 
550
.TP
 
551
default libcgroup configuration file
 
552
.PD 
 
553
 
 
554
.SH SEE ALSO
 
555
To be defined...
 
556
 
 
557
.SH BUGS
 
558
Parameter values can be only single string without spaces.
 
559
Parsing of quoted strings is not implemented.
 
560
 
 
561
.SH
 
562