1
Please follow the following steps (TODO: Automate these steps)
3
0. Update package version in AC_INIT (configure.in)
4
1. Tag the current sources in trunk to the specified version
5
1. Run autoreconf -i to generate the configure file again
6
(on changing any of the automake files)
7
2. Run configure with --prefix=<desired prefix> default is /usr/local
8
3. This step should generate
11
4. To build the RPM, carry out the following steps (obsolete, will be revised)
12
a. Create a tag with the same version as specified in step 0
14
b. copy tarball and spec file to correct place in the RPMBUILD
15
c. Build an rpm of the spec file
21
After cgroup system has taken shape, its time to have some basic tools
22
in user space which can enable a user to use the resource management
23
functionality effictively.
25
One of the needed functionality is rule based placement of a task. In general,
26
there can be either uid or gid or exec based rules. Admin/root will
27
control/enforce uid/gid based rules and exec based rules can be defined by
28
user in a config file residing in user's home dir and fully controlled by user.
30
uid/gid based rules will be defined in /etc/cgrules.conf config file and
31
this file will be managed by root.
33
Basic idea is that to begin with provide facility to implement rules
34
based on uid and gid. So a hierarchy might look like as follows.
45
Admin will write rules to control the resources among users. Then users
46
can manage their own cgroup at their own (proj1 and proj2) and control
47
the resources as they want.
49
Following are the few methods using which tasks can be placed in right
52
- Use pam_cgroup PAM plugin which will make sure users are placed in right
53
cgroup at login time and any tasks launch after login, will continue to run
56
- Use command line tool "cgexec" to launch the task in right cgroup.
58
- Modify the program and use libcgroup provided APIs for placing a task
59
in right cgroup before doing exec().
61
- Use "cgclassify" tool to classify a already running task.
63
- May be, a user space daemon can also be implemented which will listen to
64
kernel events and place the task in right group based on the rules.
65
This method involves few concerns.
67
- Reliability of netlink socket. Messages can be dropped.
68
- Change the netlink with a cgroup controller which exports the
71
- Delay incurred since the event took place and task was actually placed
74
- daemon will interfere with container's tasks which is not desired.
81
To use "cgexec" to place the task in right cgroup.
84
- Run a task using cgexec. Following is the cgexec syntax.
86
cgexec [-g <list of controllers>:<relative path to cgroup>] command [arguments]
88
Note: Cgroup controllers and path are optional. If user does not know the
89
right cgroup, cgexec will automatically place the task in right
90
cgroup based on /etc/cgrules.conf
94
cgexec -g cpu,memory:test1 ls -l
95
cgexec -g cpu,memory:test1 -g swap:test2 ls -l
99
To use "cgclassify" to place task in right cgroup.
102
- Pick a task's pid to be classified, and run
103
cgclassify <list of pids>
109
Note: After classification check out whether tasks 2140 and 4325
110
are in the right cgroup or not (Based on rules in /etc/cgrules.conf)
114
To use a pam plugin which will automatically place the task in right
117
- Build pam_cgroup.so
119
- Copy pam_cgroup.so to /lib/security/
120
- Edit /etc/pam.d/su to make use of pam_cgroup.so session module upon
124
Add following line at the end of /etc/pam.d/su file
126
session optional pam_cgroup.so
128
- Now launch a shell for a user "xyz" using su and the resulting shell
129
should be running in the cgroup designated for the user as specified
134
Try similar things with other services like sshd.
136
Note: pam_cgroup.so moves the service providing process in the right cgroup
137
and not the process which will be launched later. Due to parent child
138
relationship, yet to be forked/execed process will launch in right
141
Ex. Lets say user root does "su test1". In this case process "su" is the
142
one providing service (launching a shell) for user "test1". pam_cgroup.so
143
will move process "su" to the user "test1"'s cgroup (Decided by the uid
144
and gid of "test1"). Now once su forks/execs a shell for user test1,
145
final shell is effectively running in the cgroup it should have been
146
running based on /etc/cgrules.conf for user test1.
151
To use cgrulesengd which will move a task to right cgroup based on
152
rules in /etc/cgrules.conf do following.
154
- build and install latest libcgroup.so
157
- specify some uid/gid based rules in /etc/cgrules.conf
158
- Mount some controllers and create an hierarchy of cgroups (matching
162
- Launch some task or login as a user to the sytem. Daemon should automatically
163
place the task in right cgroup.
167
Q. Why admin should not control "exec" based rules.
168
A. Unix file system provides access control only based on uid/gid. So
169
even if admin starts putting tasks based on uid/gid, it can't enforce
170
it. For example, consider following scenario.
172
Lets say an admin creates following cgroup hierarchy.
178
user1 user2 user1 user2
180
Now admin wants to run all the database jobs under /container/database/
181
and all the firefox jobs under /container/browser/. Based on which user
182
launched it, jobs should go in either user1 or user2 dir.
184
Now assume that database subdir has to more cpu resources as compared to
185
browser subdir. Then a user, say user2, can always move his browser job
186
also to /container/database/user2 dir to get more cpu resources and
187
admin will not be able to control that.
189
[Note: user2 will control what tasks can be added in /container/database/user2
190
and will contol what further subdirs can be created under user2 dir. Root
191
should not restrict the control to root only for practical purposes. Its
192
something like that till /container/databse, admin controls the resources
193
and below that how resources are further subdivided among various projects
194
should be controlled by respective user].
196
In the light of above, it seems to make more sense that admin should enforce
197
rules only based on uid and gid. Probably later we can have a per user exec
198
based rules config file (~/.cgrules.conf), which can be parsed by cgrulesd
199
and then jobs launched by user will be placed in right cgroup based on
200
combination of rules in /etc/cgrules.conf and ~/cgrules.conf.
added
removed
README
