Jan Safranek [Thu, 29 Oct 2009 14:48:06 +0000 (15:48 +0100)]
Allow cgcreate to create unlimited nr. of groups
Don't limit the number of groups cgcreate can create, allocate them
dynamically. The size of allocated space for the group is only aproximate, but
still should be better than hard CG_HIER_MAX.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Jan Safranek [Thu, 29 Oct 2009 14:47:52 +0000 (15:47 +0100)]
Remove the CG_HIER_MAX from tools-common
Some libcgroup tools are limited to CG_HIER_MAX arguments. This hard limit
is suitable only to some of the tools, namely cgdelete and cgcreate should not
be limited to any particular numbers of groups to create/delete.
This patches removes the hard limit from tools-common.c and puts it to the
individual tools.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Jan Safranek [Fri, 23 Oct 2009 12:10:25 +0000 (14:10 +0200)]
Don't link with -lpam unless necessary II
Oops, I sent older working version, here is correct one. I need to rest :(.
Here is the correct one:
All binaries are compiled with '-lpam' if --enable-pam is specified (and it
is on by default). We want only the PAM module linked with it.
The autoconf manual says about AC_CHECK_LIB:
If action-if-found is not specified, the default action prepends
-llibrary to LIBS
And the action-if-found we used was '[]', i.e. empty -> -lpam was added to
LIBS -> everything links with it. Simple action-if-found overrides this
default.
Changelog:
- use 'dnl' as comments and ':' as the 'noop' action to reflect autoconf
coding style.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Jan Safranek [Mon, 26 Oct 2009 14:28:16 +0000 (15:28 +0100)]
Change the libcgroup group
IMHO libcgroup is not part of "Development/Libraries" group - only the devel
subpackage is. Question is, part of which group it is. Looking at
https://fedoraproject.org/wiki/RPMGroups, I like "System
Environment/Libraries" (the package provides library) or "Applications/System"
the package provides various system tools).
What is your opinion?
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Description:
create tool which shows cgroups which are on system:
Usage: lscgroup [<controllers>:<path>] [...]
list all cgroups
Changes since V1(the previous versions was not enumerated):
* fix the format of comments which have more than 1 line
* printf of help -> fprintf(stdout,...
* change the sequence of processing of cgroups on input (now
first) and internal controller list(first in the previous version), now the
cgroups are output in order in which they are put to input
* fix return values/error messages - now if the controller is not mount
the tool return error - it returns 0 otherwise
Changes since V2
* fix problem with slash characters
( $ lscgroup cpu:/1/2
cpu:/1/2/
cpu:/1/2/1
$ lscgroup cpu:1/2
cpu:/2/
cpu:/2/1 )
Changes since V3
* rename the variables (dp1 -> cgroup_dir_path, dp2 -> input_dir_path)
* improve the coding style
If a cgrulesengd daemon receives a SIGUSR2 signal (for reloading rules
configuration) while waiting in select(), a daemon finishes incorrectly
due to an "Interrupted system call" error.
If applying a patch "Add the strings of errno to cgrulesengd daemon's
message." and running `service cgred reload`, you can see the message
"selecting error: Interrupted system call". This patch fixes the problem.
There were some problems the deadlock happens related to a SIGUSR2 signal
and they have been fixed by the followings already:
The above two patches fixed the problems by protecting the important
codes from receiving a SIGUSR2 signal. But this way was not good, because
the protecting code will be necessary if increasing the important codes.
Instead of protecting the important codes, this patch restricts the
effective range of receiving SIGUSR2 signal. So we will not need to add
a new protecting code by this patch.
Add the strings of errno to cgrulesengd daemon's message.
Hi,
This patch adds the strings of errno to cgrulesengd daemon's message.
For investigating a problem that cgrulesengd daemon finishes by
`service cgred reload`, I added the strings of errno to the daemon's
message. This strings were useful for investigating.
Description:
Show controller, which are mounted/which are on input
and if option -m is used shows the mount point on which are mounted:
Changes since V1(the previous versions was not enumerated):
* fix the size of array cont_name - so no allocation and c_max variable
removed
* change the sequence of processing of controllers list on input (now
first) and internal controller list(first in the previous version), now the
controllers are output in order in which they are put to input
* fix return values/error messages - now if the controller is not mount
the tool return error - it returns 0 otherwise
Changes since V2
* fix the format of comments which have more than 1 line
Changes since V3
* printf of help -> fprintf(stdout,
Jan Safranek [Thu, 6 Aug 2009 12:03:32 +0000 (14:03 +0200)]
Remove warnings from test_functions.c
Fix following warnings:
test_functions.c: In function ‘group_modified’:
test_functions.c:435: warning: format ‘%d’ expects type ‘int *’, but argument
3 has type ‘_Bool *’
test_functions.c:440: warning: format ‘%lld’ expects type ‘long long int *’,
but argument 3 has type ‘int64_t *’
test_functions.c:445: warning: format ‘%llu’ expects type ‘long long unsigned
int *’, but argument 3 has type ‘u_int64_t *’
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Jan Safranek [Thu, 6 Aug 2009 12:03:26 +0000 (14:03 +0200)]
Remove unnecessary includes from libcgroup.h
libcgroup.h includes some header files, which are not then used. These should
be removed, resp. moved to the source files where they are actually needed.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Dhaval Giani [Thu, 6 Aug 2009 06:33:18 +0000 (12:03 +0530)]
libcgroup: Use the correct data type in the get_all_controller test case
get_all_controller.c: In function ‘main’:
get_all_controller.c:18: warning: passing argument 1 of ‘cgroup_get_all_controller_begin’ from incompatible pointer type
get_all_controller.c:23: warning: passing argument 1 of ‘cgroup_get_all_controller_next’ from incompatible pointer type
get_all_controller.c:31: warning: passing argument 1 of ‘cgroup_get_all_controller_end’ from incompatible pointer type
The test case used a FILE * instead of a void *. Correct this change (The datatype is opaque to the caller)
add api for generating the list of all controllers (not only mount ones)
this patch add api for generating the list of all controllers (not only mount ones)
- it uses three functions:
cgroup_get_all_controller_begin
cgroup_get_all_controller_next
cgroup_get_all_controller_end
and structure:
struct controller_data {
char name[FILENAME_MAX];
int hierarchy;
int num_cgroups;
int enabled;
};
the data are read from /proc/cgroups file
Signed-off-by: Ivana Hutarova Varekova <varekova@redhat.com> Reviewed-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Jan Safranek [Tue, 4 Aug 2009 12:28:29 +0000 (14:28 +0200)]
Refactor cgclear to use new recursive delete
Let's rework cgroup_config_unload_controller to use the brand new recursive
removal of groups. It saves *lot of* fopen() and fclose() calls:
On my (semi-broken) Fedora 11 with 196 running processes and 3 cgroup
hierarchies, the old cgclear does 668 open("*/tasks"). With the
optimized cgclear, I can see just 22 open("*/tasks") calls.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Jan Safranek [Tue, 4 Aug 2009 12:28:22 +0000 (14:28 +0200)]
Add cgdelete tool
The cgdelete command line tool removes given control groups.
Usage: cgdelete [-r] <controllers>:<group> [...]
# I have group 1 with many subgroups:
$ cgdelete cpu,freezer:1
cgdelete: cannot remove group '1': Cgroup generic error, error message:
Device or resource busy
$ cgdelete -r cpu,freezer:1
$
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Jan Safranek [Tue, 4 Aug 2009 12:28:15 +0000 (14:28 +0200)]
Add recursive cgroup_delete_cgroup_ext.
Changelog:
- add braces to cgroup_delete_cgroup_ext to improve readability
- use enum instead of macro to define flags
The new function allows to recursively delete whole tree of groups. There is
new infrastructure created around (cg_delete_cgroup_controller_recursive).
It has inconsistent behavior when root group removal is requested - it removes
all children (if requested), but does not remove the root itself and returns
success value. This allows simple rewrite of cgclear functions to use this
function.
Original cgroup_delete_cgroup now leads to cgroup_delete_cgroup_ext.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Jan Safranek [Tue, 4 Aug 2009 12:28:09 +0000 (14:28 +0200)]
Split cgroup removal to separate functions.
Changelog:
- simplify error handling in cg_move_task_files
cgroup_delete_cgroup does all the stuff on it's own. This patch refactors
the function and moves the parts with complete error handling.
The new functions are cg_delete_cgroup_controller and cg_move_task_files.
They are not necessarily needed, but it simplifies error handling and clearly
distinguishes functionality of cgroup_delete_cgroup.
Purpose of the functions should be clearly specified in the doxygen comments.
Especially note that cg_delete_cgroup_controller wants already opened file,
where all tasks should be moved - this is optimization, which will be used in
subsequent patches. I could use cgroup_get_task_* and cgroup_attach_task, which
would look definitely nicer, but it would lead to lot of fopen() and fclose()
calls. Let me know what do you think about it.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Jan Safranek [Tue, 28 Jul 2009 14:20:25 +0000 (16:20 +0200)]
RFC: Fix cgroup_find_parent function
There are more issues with cgroup_find_parent function:
1.
The cgroup_find_parent expects, that it's argument is group in
cg_mount_table[0] controller, which is not always the case.
IMHO the function should accept complete struct cgroup and find real parent.
2.
when checking the st_dev of the group and it's parent to prevent
"underflow" to real filesystem, actually the parent and it's parent are
checked instead of group and it's parent.
In addition, I enhanced the function to return real error code when something
goes wrong.
Open question is, if the function should return just char* as parent's
name or whole struct cgroup*. The second case is more natural - we should
work with groups and not group names, but in some cases just the name is
needed and whole cgroup creation would be unnecessary overhead (I have
prepared cgcdelete tool, which needs just parent's name).
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Add a process name to the log of cgrulesengd daemon.
Hi,
Current cgrulesengd daemon changes the cgroup of each process by a rule
based on uid, gid, and process name. And it is good that the log of the
daemon contains a process name with uid and gid.
This patch adds a process name to the log message.
Reduce "Cgroup change for PID:X, UID:X, GID:X FAILED!" messages.
Hi,
Changelog since v1:
===================
* Rebase the latest code.
* Cleanup.
The log message "Cgroup change for PID:X, UID:X, GID:X FAILED!" is output
by cgrulesengd daemon, even if a process finished already and that is not
a problem.
This patch prevents the daemon from outputting this spam log message.
Ken'ichi Ohmichi [Tue, 30 Jun 2009 00:02:37 +0000 (09:02 +0900)]
Fix cgroup_find_matching_rule() call.
Hi,
If compiling the latest code (8cc1d9743201cb9ae9a5286c898b9d47e318ed46),
the following warning messages are printed. The problem is due to invalid
call of cgroup_find_matching_rule_uid_gid(). Instead of this function call,
cgroup_find_matching_rule() should be called as
"[PATCH-v6 03/11] Add the key "process name" to find a matching rule.".
$ make
[snip]
api.c: In function 'cgroup_change_cgroup_flags':
api.c:1994: warning: passing argument 3 of 'cgroup_find_matching_rule_uid_gid' from incompatible pointer type
api.c: At top level:
api.c:1923: warning: 'cgroup_find_matching_rule' defined but not used
[snip]
$
* Reference:
"[PATCH-v6 03/11] Add the key "process name" to find a matching rule."
http://sourceforge.net/mailarchive/message.php?msg_name=4A44617E.9060002%40mxs.nes.nec.co.jp
Ivana Varekova [Fri, 19 Jun 2009 15:08:13 +0000 (17:08 +0200)]
cgset: Change the generation of cgroup
- This patch change the system of generating cgroup to
1/ create one src cgroup
2/ for each input cgroup name cgroup_copy_cgroup
the name-value data from original one
This method is better because the name-values pairs should not be
parsed several times. And this method will be used in new coption
--copy-from too (the src group will be find in option)
move the part in which src is generated to separate function
Signed-off-by: Ivana Varekova <varekova@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Ken'ichi Ohmichi [Thu, 25 Jun 2009 00:12:00 +0000 (09:12 +0900)]
Cleanup: Clarify the number meanings of string length.
Hi,
This patch clarifies the number meanings of string length in the function
cgroup_get_uid_gid_from_procfs(). This is recreated based on Igawa-san's
patch for the latest code.
The functions get a process information from /proc fs, and they are
fragile because the content of /proc fs is not stable. If changing
/proc fs in future, this test command will be useful for catching
the change.
Ken'ichi Ohmichi [Fri, 26 Jun 2009 05:51:33 +0000 (14:51 +0900)]
Apply a new rule to 'cgclassify' command.
Hi,
Changelog of v6:
================
* Change the cgroup_get_procname_from_procfs() calling for the
returning value's change.
Changelog of v5:
================
* Add the description of a new option "--sticky".
Changelog of v4:
================
* Add a new option "--sticky" so that cgrulesengd daemon does not change
the children's cgroups which is classified by 'cgclassify' command.
Changelog of v3:
================
* New patch.
Description:
============
This patch applies a new rule to 'cgclassify' command.
Ken'ichi Ohmichi [Fri, 26 Jun 2009 05:51:20 +0000 (14:51 +0900)]
Apply a new rule to 'cgexec' command.
Hi,
Changelog of v6:
================
* No change.
Changelog of v5:
================
* Add the description of a new option "--sticky".
Changelog of v4:
================
* Add a new option "--sticky" so that cgrulesengd daemon does not change
the children's cgroups which is executed by 'cgexec' command.
Changelog of v3:
================
* Set a SETUID to "cgexec" command file.
* An euid is changed to the executing user from a root user.
Changelog of v2:
================
* New patch.
Description:
============
This patch applies a new rule to 'cgexec' command.
cgroup_register_unchanged_process() is called so that cgrulesengd
daemon does not change the cgroup of a process, which is executed
by 'cgexec' command.
And cgroup_change_cgroup_flags() is called for applying a new rule.
Ken'ichi Ohmichi [Fri, 26 Jun 2009 05:51:06 +0000 (14:51 +0900)]
Add the library function cgroup_register_unchanged_process().
Hi,
Changelog of v6:
================
* No change.
Changelog of v5:
================
* Rebase the patch to the latest code.
Changelog of v4:
================
* No change.
Changelog of v3:
================
* No change.
Changelog of v2:
================
* New patch.
Description:
============
This patch adds the library function cgroup_register_unchanged_process()
for notifying cgrulesengd daemon of the unchanged process.
Ken'ichi Ohmichi [Fri, 26 Jun 2009 05:50:54 +0000 (14:50 +0900)]
Add the handler of unchanged process to cgrulesengd daemon.
Hi,
Changelog of v6:
================
* No change.
Changelog of v5:
================
* No change.
Changelog of v4:
================
* Add the comment "FIXME: Change the temporary file to configurable one."
* Define the number of allocation.
Changelog of v3:
================
* Set the value 0x1 to CGROUP_DAEMON_UNCHANGE_CHILDREN flag.
Changelog of v2:
================
* New patch.
Description:
============
This patch adds the handler of unchanged process to the cgrulesengd daemon.
By this patch, the daemon does not change a process which is executed by
'cgexec' command, because it is possible to notify the unchanged process to
the daemon by using "unix domain socket".
Ken'ichi Ohmichi [Fri, 26 Jun 2009 05:50:31 +0000 (14:50 +0900)]
Cleanup: Separate the netlink method to cgre_receive_netlink_msg().
Hi,
Changelog of v6:
================
* No change.
Changelog of v5:
================
* No change.
Changelog of v4:
================
* Remove unused parameter "cn_hdr" from cgre_receive_netlink_msg().
Changelog of v3:
================
* No change.
Changelog of v2:
================
* New patch.
Description:
============
This patch separates the netlink method for the readability, because
the later patch [PATCH 6/9] adds "unix domain socket" handling method
around the netlink method.
Ken'ichi Ohmichi [Fri, 26 Jun 2009 05:50:09 +0000 (14:50 +0900)]
Add a exec event to the event handler of cgrulesengd daemon.
Hi,
Changelog of v6:
================
* Change the cgroup_get_procname_from_procfs() calling for the
returning value's change.
Changelog of v5:
================
* No change.
Changelog of v4:
================
* No change.
Changelog of v3:
================
* No change.
Changelog of v2:
================
* No change.
Description:
============
A process name is changed when execve(2), so a new rule based on
process name should be applied when execve(2) happens.
Then this patch adds an EXEC event to the event handler.
Ken'ichi Ohmichi [Fri, 26 Jun 2009 05:49:50 +0000 (14:49 +0900)]
Add the key "process name" to find a matching rule.
Hi,
Changelog of v6:
================
* No change.
Changelog of v5.1:
==================
* BUGFIX: Clear the flags meaning "found a matching rule"
when a process name does not match.
There was a problem that cgexec and cgclassify didn't work correctly
if a user executes cgexec/cgclassify based on /etc/cgrules.conf.
For example, if a root user executes `cgclassify $$` on the following
/etc/cgrules.conf, the process ($$) should be moved to users/root on
cpuset and memory subsystems. But the process was moved to users/root/cp
on memory subsystem only.
Example of /etc/cgrules.conf:
=============================
root:cp cpuset users/root/cp
% memory users/root/cp
root cpuset users/root
% memory users/root
The cause is why the flags meaning "found a matching rule" (uid, gid, and
matched) is not cleared when a process name does not match. This problem
is fixed on this patch.
Changelog of v5:
================
* Rebase the patch to the latest code.
Changelog of v4:
================
* No change.
Changelog of v3:
================
* BUGFIX: Fix the handling of '%' in /etc/cgrules.conf.
Changelog of v2:
================
* Use strcmp() instead of strncmp() for checking a process name strictly.
* Some cleanups.
Description:
============
This patch adds the key "process name" to find a matching rule.
Ken'ichi Ohmichi [Fri, 26 Jun 2009 05:49:36 +0000 (14:49 +0900)]
Add the parser of process name in /etc/cgrules.conf.
Hi,
Changelog of v6:
================
* The definations of CGROUP_RULE_MAXKEY and CGROUP_RULE_MAXLINE are
moved to libcgroup-internal.h since no one from outside should be
using them.
Changelog of v5:
================
* Rebase the patch to the latest code.
Changelog of v4:
================
* Use more safety length of a user name for the buffer "username".
* Move the macros min()/max() to src/libcgroup-internal.h for using
in src/api.c also.
Changelog of v3:
================
* Fix unclear buffer of user by memset().
Changelog of v2:
================
* Remove unnecessary memset().
* Some cleanups.
Description:
============
This patch adds the parser of process name in /etc/cgrules.conf.
A new rule based on process name is as the following, and the process
name is stored into the member "procname" in struct cgroup_rule.
<user>:<process name> <controllers> <destination>
Ken'ichi Ohmichi [Fri, 26 Jun 2009 05:49:16 +0000 (14:49 +0900)]
Add cgroup_get_procname_from_procfs() for getting a process name.
Hi,
Changelog of v6:
================
* Change the returning values of *_get_procname_from_proc*() to integer
from charactor pointer.
* Clarify the number meaning of string length in cg_get_procname_from_
~proc_status()
Changelog of v5:
================
* Rebase the patch to the latest code.
Changelog of v4:
================
* Add the error handling for strdup()'s error.
* Reduce strlen() calls.
* Make the check code of a process name simple.
Changelog of v3:
================
* Move cgroup_get_procname_from_procfs() to libcgroup-internal.h.
* Fix unclear buffer of buf_cwd by memset().
* Get a real path of script file by realpath().
Changelog of v2:
================
* It is possible to handle a process, which name length is over than
16 characters, also.
Description:
============
This patch adds a new function cgroup_get_procname_from_procfs()
for getting a process name.
This function allocates the memory for a process name, and writes
the name to the memory, and returns the pointer of the memory.
So a caller should free the memory if unusing it.
The process name, which is wrotten by this function, depends on
the specified process:
If a command process) the full path of command.
If a shell script process) the full path of shell script.
If a kernel thread) the process name of kernel thread.
Dhaval Giani [Fri, 26 Jun 2009 17:36:18 +0000 (23:06 +0530)]
libcgroup: Introduce an API to get the mount point of a specific subsystem
Introduce an API which will query the mount table and return the mount point
of a specific subsystem. This is needed in the case when the user knows which
subsystem he wants the details of, which would make the use of the get_controller*
APIs cumbersome.
$ make
[snip]
api.c: In function 'cgroup_walk_tree_begin':
api.c:2350: warning: passing argument 3 of 'cg_walk_node' makes integer from pointer without a cast
api.c:2315: warning: unused variable 'fts'
[snip]
$
Dhaval Giani [Mon, 22 Jun 2009 11:50:09 +0000 (17:20 +0530)]
libcgroup: Introduce a unload cgroups API
This API will unload the cgroups created in the cgroupfs and
unmount and delete the filesystem mount point. The action is
equivalent to what is done currently in service cgconfig stop.
The reason for this API is to make sure we don't end up with a
asymmetric library API subset. Today an application program can
programatically through cgroup_config_load_config() load a
configuration file, but has no means to cleanup (including all
temporarily created groups).
changes from v3
1. Address Jan's comments from http://article.gmane.org/gmane.comp.lib.libcg.devel/1105
changes from v2
1. Fix a leak as noted by Bharata
2. Address Balbir's review comments at
http://article.gmane.org/gmane.comp.lib.libcg.devel/1080
changes from v1
1. Change the name of the function to cgroup_unload_cgroups
2. Change the name of the executatble to cgclear
3. Split out the funtions
Dhaval Giani [Thu, 18 Jun 2009 14:12:48 +0000 (19:42 +0530)]
libcgroup: Introduce get_controller API
This set of APIs will allow the caller to query the mount table
and find out what controller is mounted at what path.
Test program has been included in the patch. Running the test program
results in
[dhaval@gondor tests]$ ../libtool --mode=execute ./get_controller
Controller cpu is mounted at /cgroup
Controller cpuacct is mounted at /cgroup
Controller memory is mounted at /cgroup1
[dhaval@gondor tests]$
Which is the setup on this system.
Changes from v2
1. Remove the incorrect comments as pointed out by Bharata
Changes from v1
1. Use a new structure as mentioned by bharata to return the values.
Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com> Cc: Jan Safranek <jsafrane@redhat.com> Acked-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Dhaval Giani [Thu, 18 Jun 2009 14:12:46 +0000 (19:42 +0530)]
libcgroup: Introduce post order walk
With the introduction of the flags, we now actually make use of them.
This patch adds a post mode and modifies the test case to also do a post
order walk.
Dhaval Giani [Thu, 18 Jun 2009 14:12:45 +0000 (19:42 +0530)]
libcgroup: Add flags to the walk_tree handle
Introduce a cgroup_tree_handle structure so that we can track flags for
the walk_tree operation. In a number of cases we would prefer to walk the
tree in postorder as opposed to pre-order which is the current default.
This patch does the addition.
Changes since V1:
1. Added checks for !handle as suggested by Bharata
Ivana Varekova [Thu, 18 Jun 2009 05:50:30 +0000 (07:50 +0200)]
Prevent to add multiple versions of the same controller to mount_table
This patche add a test to cgroup_init function, which prevent to add
multiple records for the same controller (this is a problem eg. in
cgroup_get_cgroup function - which looks to mount table and add all
relevant controllers using cgroup_add_controller function and when the
function calls cgroup_add_cgroup function twice on the same controller,
it returns error so the result is cgroup_get_cgroup failed).
Signed-off-by: Ivana Varekova <varekova@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
There are some similar functions for getting process's data (uid, gid) from
/proc/<pid>/status file, so this patch integrates these functions into one
cgroup_get_uid_gid_from_procfs().
Ivana Varekova [Wed, 3 Jun 2009 07:37:05 +0000 (09:37 +0200)]
This patch adds cgcreate tool
This patch adds cgcreate tool, which creates cgroups based on input
parameters - the syntax is:
cgcreate -t <tuid>:<tgid> -a <agid>:<auid> -g <list of
controllers>:<relative path to cgroup>
where:
-a enables user to define admin gid and uid (implicit values are the
same values which are in the parent directory)
-t enables user to define task gid and uid (implicit values are the
same values which are in parent directory)
-g sets pairs list of controllers-relative path to cgroup
-------------------------------------------------
EXAMPLES:
* ../../libtool --mode=execute ./cgcreate -a :varekova -g cpuacct:first
* ll /mnt/cgroups/cpuacct | grep first
drwxrwxr-x 2 root varekova 0 2009-06-03 09:14 first
Jan Safranek [Mon, 25 May 2009 07:48:34 +0000 (09:48 +0200)]
Add options to enable/disable various build targets.
By default, everything is compiled. I want to add options to ./configure,
which can selectively disable tools, daemon and pam module. The library
itself is mandatory component and cannot be disabled.
Ivana Varekova [Fri, 22 May 2009 11:11:04 +0000 (13:11 +0200)]
configure.in problem with byacc and flex
fix the problem - can be applied now :)
configure.in file wrongly handles YACC and LEX variables so ./configure
exit succesfully, but make fails.
The problems are:
* it enables configuration even if no yacc is installed (it is necessary
for make) - YACC is set to byacc in this case
* the configure.in enables configuration if no lex is installed (it is
again necessary for succesfull make) - in this case YAC is set to ":" i
Signed-off-by: Ivana Varekova <varekova@redhat.com> Acked-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Ken'ichi Ohmichi [Tue, 19 May 2009 00:19:29 +0000 (09:19 +0900)]
Fix the deadlock of rl_lock.
Hi,
Changelog of v2:
- Add the description of the problematic call sequence.
- There is not any change in the code.
[PATCH-v2] Fix the deadlock of rl_lock.
For avoiding the deadlock, protect cdgroup_change_cgroup_uid_gid_flags()
by blocking SIGUSR2 signal.
The problematic call sequence is the following:
----------------------------------------------------------------------
* CGRULESENGD DAEMON *
<< cgre_flash_rules() is the signal handler for SIGUSR2 signal >>
cgre_create_netlink_socket_process_msg()
<< Receive a UID/GID event packet >>
cgre_handle_msg()
cgre_process_event()
cgroup_change_cgroup_uid_gid_flags()
cgroup_find_matching_rule_uid_gid()
pthread_rwlock_wrlock(&rl_lock); << Get the lock of rl_lock >>
<< Receive a SIGUSR2 signal, and switch to cgre_flash_rules() >>
cgre_flash_rules()
cgroup_reload_cached_rules()
cgroup_parse_rules()
pthread_rwlock_wrlock(&rl_lock); << deadlock ! >>
----------------------------------------------------------------------
A cgrulesengd daemon needs a lock of rl_lock for referring configuration
buffer. On the other way, the daemon reloads configuration file when
receiving SIGUSR2 signal, and it needs the same lock in cgroup_parse_rules().
So cgroup_change_cgroup_uid_gid_flags() should be protected from SIGUSR2
signal for avoiding the deadlock.
Ken'ichi Ohmichi [Fri, 15 May 2009 08:30:24 +0000 (17:30 +0900)]
Fix the deadlock of vsyslog() call.
Hi,
I found the deadlock problem that a cgrulesengd daemon stalls if
service "cgred" is reloaded while many UID events happen.
The following is the gdb output by attaching the stalling daemon:
(gdb) bt
#0 0x0000003b298dd918 in __lll_mutex_lock_wait () from /lib64/libc.so.6
#1 0x0000003b298ce847 in _L_lock_646 () from /lib64/libc.so.6
#2 0x0000003b298ce2da in __vsyslog_chk () from /lib64/libc.so.6
#3 0x0000000000401533 in flog (level=5, format=0x402778 "Reloading rules configuration.") at cgrule sengd.c:130
#4 0x00000000004015d1 in cgre_flash_rules (signum=<value optimized out>) at cgrulesengd.c:644
#5 <signal handler called>
#6 0x0000003b298d27b5 in send () from /lib64/libc.so.6
#7 0x0000003b298ce3a0 in __vsyslog_chk () from /lib64/libc.so.6
#8 0x0000000000401533 in flog (level=4, format=0x402b82 "Failed to open %s") at cgrulesengd.c:130
#9 0x0000000000401cc7 in cgre_process_event (ev=0x7fff8ad11cc4, type=4) at cgrulesengd.c:161
#10 0x0000000000401fd5 in cgre_create_netlink_socket_process_msg () at cgrulesengd.c:486
#11 0x00000000004023ca in main (argc=1, argv=<value optimized out>) at cgrulesengd.c:878
(gdb)
We can see __vsyslog_chk() is called twice, because the daemon
recieved a SIGUSR2 signal in __vsyslog_chk(). In __vsyslog_chk(),
"syslog_lock" is locked by __libc_lock_lock(syslog_lock).
So I think vsyslog() should be protected by blocking the signal,
and this patch fixes the problem by doing it.
Ken'ichi Ohmichi [Fri, 15 May 2009 00:39:28 +0000 (09:39 +0900)]
Specify the full path of cgrulesengd command in cgred.
Hi,
I installed libcgroup by `make install`, and the service "cgred"
didn't work like the following:
# service cgred start
Starting CGroup Rules Engine Daemon...
/bin/bash: cgrulesengd: command not found
[FAILED]
#
The cause is why the function "daemon" cannot find cgrulesengd
command. This patch fixes the problem by specifying the full path
of cgrulesengd command.
Jan Safranek [Tue, 14 Apr 2009 11:52:47 +0000 (13:52 +0200)]
Generate paths in initscripts by configure script
Change the hardcoded paths in initscripts to dynamically generated ones. The
real executable path $bindir can be constructed using $prefix and $exec_prefix
variables, therefore it's necessary to define also these two.
The patch includes removal of old initscripts from git - they are generated
from .in file now.
I did not run autoreconf, I think the generated junk is being removed from git
soon.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
I tested a cgrlesengd daemon with huge load, which makes many 'su',
in long time. And the daemon was killed by an OOM killer. So the
daemon has memory leak. This patch fixes this problem.
The daemon allocates memory at cg_prepare_cgroup(), but it does not
free the memory. This patch adds necessary free() to cgroup_change_
cgroup_path by calling cgroup_free_controllers(). In addition, this
patch adds free()s for handling error and flushes the counters of the
allocations in cgroup_free_controllers().
Changelog v2:
* Use clock_gettime(2) for getting timestamp since a system boot.
* Change parent_info's memory to dynamic allocation.
This patch is for changing the cgroup of a forked process while parent
changing.
This patch adds the following sequence:
1. Store both the timestamp and the process-id when changing the cgroup.
2. If receiving a PROC_EVENT_FORK packet, check its parent-pid and its
timestamp.
3. If its parent-pid and the stored process-id are same and its timestamp
is older than the stored timestamp, change the cgroup of forked process.
I have been testing a cgrulesengd daemon and I noticed it fails to
change the cgroup of child occasionally. I tested it by following
configulation file:
A cpuset subsystem and a memory subsystem are mounted on different
mount points, and a cgrulesengd daemon manages each subsystem.
I login this environment as a user "user01", and each susbystem's
tasks file is the following:
They should be the same, but they are different. I investigated this
problem, and I found the cause. The reason is that the process(31806)
was forked just after writing the process(31805) to a cpuset subsystem's
tasks file:
<1> The UID/GID CHANGE event of the process 31805 happens.
<2> The daemon writes "31805" to a cpuset subsystem's tasks file.
<3> The process 31806 is forked, and it appears on a cpuset subsystem's
tasks file.
<4> The daemon writes "31805" to a memory subsystem's tasks file.
<5> The process 31806 does not appears on a memory subsystem's tasks file.
For solving this problem, I propose the following sequence.
1. Store both the timestamp and the process-id when the step <4>.
2. If receiving a PROC_EVENT_FORK packet, check its parent-pid and its
timestamp.
3. If its parent-pid and the stored process-id are same and its timestamp
is older than the stored timestamp, change the cgroup of forked process.
Changelog of v2:
* Change only [PATCH 2/2] and there is not any changes in [PATCH 1/2].
This patch adds the method for getting euid/egid from /proc/<pid>/status
file.
For changing the cgroup of a forked process, the method is usefull because
a PROC_EVENT_FORK packet does not inform of its euid and its egid.
projects / thirdparty / libcgroup.git / log
