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.
This is the test case for the new API. This test takes one argument, the
group name.
Sample run on my system with this test case returns,
[dhaval@gondor tests]$ ../libtool --mode=execute ./walk_task a
Printing the details of groups a
Pid is 6092
Pid is 11315
Pid is 11318
Pid is 11319
Pid is 11324
Pid is 13234
[dhaval@gondor tests]$
gcc -DHAVE_CONFIG_H -I. -I.. -I../include -g -O2 -Wall -MT api.lo -MD -MP -MF .deps/api.Tpo -c api.c -fPIC -DPIC -o .libs/api.o
api.c:52:1: warning: "VERSION" redefined
In file included from ./libcgroup-internal.h:21,
from api.c:31:
../config.h:129:1: warning: this is the location of the previous definition
api.c: In function 'cgroup_parse_rules':
api.c:353: warning: implicit declaration of function 'isblank'
api.c: In function 'cgroup_modify_cgroup':
api.c:1073: warning: implicit declaration of function 'asprintf'
This patch fixes the warning arising due to isblank, asprintf and getline.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Remove the dependency of libcgroup on libcgroup build.
libcgroup build checks for the availability of cgroup_creat_cgroup
from libcgroup during its build. This causes a build failure if
libcgroup is compiled in a system which already has libcgroup library
installed.
Remove this check from configure.in.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Two pthread_rwlock_unlock() calls are necessary if *cgroup is null
and fprintf()/fflush() fails in cgroup_attach_task_pid():
src/api.c:785
785 pthread_rwlock_rdlock(&cg_mount_table_lock);
786 for(i = 0; i < CG_CONTROLLER_MAX &&
787 cg_mount_table[i].name[0]!='\0'; i++) {
[snip]
805 ret = fprintf(tasks, "%d", tid);
806 if (ret < 0) {
<<pthread_rwlock_unlock() call is necessary>>
807 cgroup_dbg("Error writing tid %d to
%s:%s\n",
808 tid, path,
strerror(errno));
809 fclose(tasks);
810 last_errno = errno;
811 return ECGOTHER;
812 }
813
814 ret = fflush(tasks);
815 if (ret) {
<<pthread_rwlock_unlock() call is necessary>>
816 last_errno = errno;
817 cgroup_dbg("Error writing tid %d to
%s:%s\n",
818 tid, path,
strerror(errno));
819 fclose(tasks);
820 return ECGOTHER;
821 }
For the readability, this patch merges almost the same lines into one
function(__cgroup_attach_task_pid()) and adds pthread_rwlock_unlock()
call for the case the function fails.
Fix infinite loop if receiving a NLMSG_NOOP packet.
Hi,
I tested 'cgred' service and I saw the problem that some processes
are not moved to a right cgroup. This problem did not occur always,
and it did sometimes. I reviewed cgrulesengd.c and found the bug
cgrulesengd stays in an infinite loop if receiving a NLMSG_NOOP
packet.
Add some success/error messages to 'cgred' service.
Hi,
The existing 'cgred' service displays a success message ([ OK ]) when
the service is starting, but it does not display any messages when it
is stopping/reloading. So this patch adds some success/error messages
to 'cgred' service like the following:
# service cgred start
Starting CGroup Rules Engine Daemon...
[ OK ]
#
# service cgred stop
Stopping CGroup Rules Engine Daemon...
[ OK ]
#
# service cgred restart
Stopping CGroup Rules Engine Daemon...
[ OK ]
Starting CGroup Rules Engine Daemon...
[ OK ]
#
# service cgred reload
Reloading rules configuration...
[ OK ]
#
This patch's purpose is almost same as the one of 'cgconfig' service:
http://sourceforge.net/mailarchive/forum.php?thread_name=49D9B778.3000900%40mxs.nes.nec.co.jp&forum_name=libcg-devel
Add some success/error messages to 'cgconfig' service.
Hi,
The existing 'cgconfig' service does not display any message even if it
succeeds. So this patch adds some success/error messages to 'cgconfig'
service like the following:
# service cgconfig start
Starting cgconfig service: [ OK ]
#
# service cgconfig stop
Stopping cgconfig service: [ OK ]
#
# service cgconfig restart
Stopping cgconfig service: [ OK ]
Starting cgconfig service: [ OK ]
#
It makes test of 'cgconfig' service a little easy.
Here is the v2 of the patch which introduces APIs to read controller
specific stats. Added Makefile.am updates which I had missed in the
previous post.
New APIs to read controller specific statistics.
This patch introduces 3 new APIs which can be used to read controller
statistics iteratively. (Eg. stats from memory.stat etc)
Reading of stats is initiated by cgroup_read_stats_begin() API, which
returns the first stat of the requested controller in addition to returing
a handle that should be used in subsequent reads.
cgroup_read_stats_next() API can be used to read the remaining stats
one by one. This needs the handle returned by cgroup_read_stats_begin().
cgroup_read_stats_end() API will terminate the stats reading iteration
initiated by cgroup_read_stats_begin().
Changelog:
v2
- Update tests/Makefile.am so that it generates appropriate rules
for tests/read_stats.c in the Makefile. This is in addition to
the manual updates done to the generated file tests/Makefile.in.
v1
- cgroup_read_stats apis now work with relative cgroup path names instead
of absolute path names.
v0
- Initial post.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Ken'ichi Ohmichi [Tue, 31 Mar 2009 02:18:27 +0000 (11:18 +0900)]
Add fclose() calls for error handling
I reviewed the libcgroup code in the viewpoint of memory-leak and
found some lacks of fclose(). This patch adds some fclose() calls
for error handling.
Jan Safranek [Mon, 30 Mar 2009 10:24:42 +0000 (15:54 +0530)]
No matter how often I test, some last-minute change screws everything up...
This time I added duplicate -version-number argument in src/Makefile.am, which
results in following compilation error:
libtool: link: CURRENT `' must be a nonnegative integer
libtool: link: `-version-number' is not valid version information
Jan Safranek [Thu, 26 Mar 2009 14:10:09 +0000 (15:10 +0100)]
Generate .tar.bz2 on 'make dist'
Automatically generate libcgroup*.tar.bz2 on 'make dist'. Some restructure
of AC_INIT and AM_INIT was needed to archieve this and correct output
filename.
Namely AC_INIT( [package], ... ) is used as resulting tarball file name now.
Also run automake and autoconf to refresh the generated stuff... Only
configure.in contains manual changes, everything else is autoconf/automake
bloat :(.
Jan Safranek [Thu, 26 Mar 2009 14:04:36 +0000 (15:04 +0100)]
Add warrning when test script is started by normal user
The runlibcgrouptest.sh will now whine when script is started by non-root
user. Root permissions are needed to create directories and mount the cgroups
there.
Jan Safranek [Wed, 25 Mar 2009 09:28:34 +0000 (10:28 +0100)]
Disable compilation of static libraries
Disable compilation of static libraries. Static libraries (.a files) should not
be compiled by default, shared library is better for LGPL licensed code.
Still, one can enable static libraries with ./configure --enable-static
Jan Safranek [Fri, 13 Mar 2009 14:16:20 +0000 (15:16 +0100)]
Add automake makefiles
Add automake makefiles and prepare everything to run, but don't actually
run the automake - it would generate lot of noise, where my manual changes
would get lots.
Jan Safranek [Fri, 13 Mar 2009 14:16:20 +0000 (15:16 +0100)]
Clean up the scripts directory
The directory contains samples and howto, which is not relevant anymore.
Sample configuration files should be in ../samples and (relevant)
documentation in ../doc
Ivana Varekova [Wed, 25 Mar 2009 07:55:57 +0000 (08:55 +0100)]
Minor fix to cgconfig init script
cgconfig script does not test the return value of cgconfigparser command
so it continues to simulate start of the service, even if it was not pass
successfuly.
This is the first part of the patch from:
http://sourceforge.net/mailarchive/forum.php?thread_name=20090120121851.GC4422%40linux.vnet.ibm.com&forum_name=libcg-devel
which was not incorporated yet.
Signed-off-by: Ivana Varekova <varekova@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Jan Safranek [Mon, 2 Mar 2009 12:09:16 +0000 (13:09 +0100)]
Add PACKAGE_VERSION to Makefile
By removing PACKAGE_VERSION in SVN rev. 344 I broke 'make install' - the macro
must be defined there, 'make install' needs it to build library symlinks.
I am sorry, I should have noticed it earlier.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Jan Safranek [Sun, 8 Mar 2009 21:43:59 +0000 (22:43 +0100)]
Move binaries and libraries to /bin and /lib
Since cgconfig starts before nfs shares are mounted, it should not use
anything on /usr (it can be on nfs too). All the libcgroup libraries and
binaries should be therefore in /.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Jan Safranek [Sun, 8 Mar 2009 21:43:51 +0000 (22:43 +0100)]
Start the config earlier
We could start cgconfig service earlier, even before network and syslog.
$local_fs is not needed, because /bin, /sbin and /etc are guaranteed by
rc.sysinit (see Fedora bug #309001,
https://bugzilla.redhat.com/show_bug.cgi?id=309001).
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Dhaval Giani [Wed, 4 Mar 2009 11:38:53 +0000 (17:08 +0530)]
libcgroup: Initialize buffer in config.c
Fix the warning,
config.c: In function ‘cgroup_config_parse_controller_options’:
config.c:104: warning: ‘buffer’ may be used uninitialized in this function
Dhaval Giani [Wed, 4 Mar 2009 11:29:49 +0000 (16:59 +0530)]
libcgroup: Removed unused functions from api.c
api.c: At top level:
api.c:1780: warning: ‘cg_prepare_controller_array’ defined but not used
api.c:1805: warning: ‘cg_free_controller_array’ defined but not used
Turns out no one is using this functions. Remove them.
Dhaval Giani [Wed, 4 Mar 2009 11:25:35 +0000 (16:55 +0530)]
libcgroup: Fix unused variable warnings for the walk_tree API
api.c: In function ‘cg_walk_node’:
api.c:2252: warning: unused variable ‘base_level’
api.c: In function ‘cgroup_walk_tree_end’:
api.c:2314: warning: unused variable ‘ret’
Dhaval Giani [Tue, 3 Mar 2009 14:51:03 +0000 (20:21 +0530)]
libcgroup: Check if the data structures have been initialized for walk_tree
The test for cgroup_init() was not being done by the walk tree APIs.
With this it is possible for it to run without cgroup_init() being
called and having mysterious failures.
Dhaval Giani [Tue, 3 Mar 2009 14:51:02 +0000 (20:21 +0530)]
libcgroup: Dont check for success of moved tasks
Sometime the movement of tasks in the default cgroup can fail for
various reasons. Therefore, do not check for the success of the
movement of tasks.
Justification: These are generally for cgroups which need some special
setup, for example the RT group scheduler. This is not handled by the
library whihc is generic. If a user is intersted in these working, they
will setup a default cgroup in the config files whihc handle everything
they need.
Dhaval Giani [Sat, 28 Feb 2009 09:27:31 +0000 (09:27 +0000)]
Feature: Provide new libcgroup walk tree API
From: Balbir Singh <balbir@linux.vnet.ibm.com>
Changelog v3..v4
1. Add _end() method for the iterator
Changelog v3..v2
1. Move to iterator based design
Changelog v2..v1
1. Add base path and depth semantics for walking
This patch adds the capability to walk cgroups by providing a new API
called cgroup_walk_tree. The API accepts the controller to walk and the
order in which the directories and files must be visited. The code is
implemented as an iterator, the begin function starts the walk and
we have depth control. The next function gets the following node
and returns ECGEOF when done.
libcgroup.map has been updated to reflect the same change and the prototype
is exported in libcgroup.h.
I've also added test cases (tests/walk_test.c). Sample output is show
root is /cgroup/cpu///
path , parent , relative /, full /cgroup/cpu///
path l3, parent , relative /l3, full /cgroup/cpu///l3
path ll1, parent l3, relative /l3/ll1, full /cgroup/cpu///l3/ll1
path lll1, parent ll1, relative /l3/ll1/lll1, full /cgroup/cpu///l3/ll1/lll1
path l2, parent , relative /l2, full /cgroup/cpu///l2
path ll1, parent l2, relative /l2/ll1, full /cgroup/cpu///l2/ll1
path lll1, parent ll1, relative /l2/ll1/lll1, full /cgroup/cpu///l2/ll1/lll1
path l1, parent , relative /l1, full /cgroup/cpu///l1
path ll1, parent l1, relative /l1/ll1, full /cgroup/cpu///l1/ll1
path lll1, parent ll1, relative /l1/ll1/lll1, full /cgroup/cpu///l1/ll1/lll1
path a, parent , relative /a, full /cgroup/cpu///a
path e, parent a, relative /a/e, full /cgroup/cpu///a/e
path f, parent e, relative /a/e/f, full /cgroup/cpu///a/e/f
path f, parent a, relative /a/f, full /cgroup/cpu///a/f
path x, parent a, relative /a/x, full /cgroup/cpu///a/x
path b, parent a, relative /a/b, full /cgroup/cpu///a/b
path c, parent b, relative /a/b/c, full /cgroup/cpu///a/b/c
path d, parent c, relative /a/b/c/d, full /cgroup/cpu///a/b/c/d
path default, parent , relative /default, full /cgroup/cpu///default
root is /cgroup/cpu//a/
path , parent , relative /, full /cgroup/cpu//a/
path e, parent , relative /e, full /cgroup/cpu//a/e
path f, parent e, relative /e/f, full /cgroup/cpu//a/e/f
path f, parent , relative /f, full /cgroup/cpu//a/f
path x, parent , relative /x, full /cgroup/cpu//a/x
path b, parent , relative /b, full /cgroup/cpu//a/b
path c, parent b, relative /b/c, full /cgroup/cpu//a/b/c
Walking the first 5 nodes
root is /cgroup/cpu///
path , parent , relative /, full /cgroup/cpu///
path l3, parent , relative /l3, full /cgroup/cpu///l3
path ll1, parent l3, relative /l3/ll1, full /cgroup/cpu///l3/ll1
path lll1, parent ll1, relative /l3/ll1/lll1, full /cgroup/cpu///l3/ll1/lll1
NOTE: Parent directory is represented by an empty (not NULL) string "".
The length of the string is 0.
Dhaval Giani [Fri, 27 Feb 2009 20:38:54 +0000 (20:38 +0000)]
libcgroup: Update specfile for v0.33 and bump up the version
From: Ivana Varekova <varekova@redhat.com>
OK, here goes
This patch Originally from Ivana and with changes I've made, get the
spec file working again (rpmlint warnings need some care and
ownership).
The new version will be 0.33 and will have new man pages and newer
API and many more bug fixes
[varekova@redhat.com] Incorporate pam module instalation to the spec file -
file part change add dependency
[balbir@linux.vnet.ibm.com] Bumped up the version, getting ready for a new
release. Updated makefile to install new man pages and to move the pam
module to the correct place at the time of installation.
Dhaval Giani [Thu, 26 Feb 2009 11:53:08 +0000 (11:53 +0000)]
bcgroup: Rename 'flash' to 'reload'
LSB specifies that 'reload' is the right initscript parameter to stimulate
daemon to reread its configuration file. I let the 'flash' still working, in
case somebody is used to it, but do not advertise it anywhere.
projects / thirdparty / libcgroup.git / log
