libcg.git, branch devel/cgdelete

Refactor cgclear to use new recursive delete

2009-07-29T13:21:39+00:00

Let's rework cgroup_config_unload_controller to use the brand new recursive
removal of groups. It saves *lot of* fopen() and fclose() calls.

Signed-off-by: Jan Safranek

Add cgdelete tool

2009-07-29T13:21:39+00:00

The cgdelete command line tool removes given control groups.

Usage: cgdelete [-r]  : [...]

Signed-off-by: Jan Safranek

Add recursive cgroup_delete_cgroup_ext.

2009-07-29T13:17:47+00:00

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

Split cgroup removal to separate functions.

2009-07-29T13:14:24+00:00

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

Export cgroup_find_parent and add testing code for it

2009-07-28T14:08:39+00:00

This patch does not necessarily need to be accepted, it just provides testing
facility for new cgroup_find_parent.

Especially note the ugly dependence on ../src/tools/tools-common.c :)

Signed-off-by: Jan Safranek

RFC: Fix cgroup_find_parent function

2009-07-28T14:08:36+00:00

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

Add a process name to the log of cgrulesengd daemon.

2009-07-07T14:35:21+00:00

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.

Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi 
Signed-off-by: Dhaval Giani

Reduce "Cgroup change for PID:X, UID:X, GID:X FAILED!" messages.

2009-07-07T14:35:21+00:00

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.

* Reference
  [PATCH 2/2] Reduce "Cgroup change for PID:X, UID:X, GID:X FAILED!" messages.
  http://sourceforge.net/mailarchive/message.php?msg_name=4A10EE7E.60403%40mxs.nes.nec.co.jp

Thanks
Ken'ichi Ohmichi

Signed-off-by: Ken'ichi Ohmichi 
Signed-off-by: Dhaval Giani

Configure the location of cgrulesengd socket

2009-07-01T15:04:50+00:00

This patch allows users to configure location of cgrulesengd socket before
compilation:

./configure --enable-cgred-socket=/var/run/cgred.socket

In addition, /var/run/cgred.socket is now default location of the socket - this
sounds LSB compliant to me. Feel free to suggest better one.

Signed-off-by: Jan Safranek 
Signed-off-by: Dhaval Giani

Cleanup: find better name for CGRULE_CGRED_TEMP_FILE

2009-07-01T15:04:49+00:00

Rename CGRULE_CGRED_TEMP_FILE to CGRULE_CGRED_SOCKET_PATH to better describe
the macro usage - it's not a temporary file, it's a socket.

Signed-off-by: Jan Safranek 
Signed-off-by: Dhaval Giani