summaryrefslogtreecommitdiffstats
path: root/src/daemon
Commit message (Collapse)AuthorAgeFilesLines
* Hi,review/daemon-execJan Safranek2009-05-261-7/+16
| | | | | | | | | | | | | | | | | | 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. TODO: ===== * The cgroup directory, which is specified by `cgexec` command, is ignored because this patch adds an EXEC event to the event handler. This problem should be fixed. Thanks Ken'ichi Ohmichi Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
* Hi,Jan Safranek2009-05-261-48/+2
| | | | | | | | | | | | | | 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_procdata_from_status(). In addition, cgroup_get_procdata_from_status() can get also a process name from /proc/<pid>/status file. Thanks Ken'ichi Ohmichi Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
* Fix the deadlock of rl_lock.Ken'ichi Ohmichi2009-05-221-7/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Thanks Ken'ichi Ohmichi Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* Fix the deadlock of vsyslog() call.Ken'ichi Ohmichi2009-05-221-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Thanks Ken'ichi Ohmichi Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* Cleanup the infinite loop of cgrulesengddaemon.Ken'ichi Ohmichi2009-05-191-2/+3
| | | | | | | | | | | | | Hi, This patch clarifies the infinite loop. Thanks Ken'ichi Ohmichi Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com> Acked-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* There is the problem that cgrulesengd cannot get Gid from /proc/PID/status,Masayuki Igawa2009-05-141-2/+0
| | | | | | | | | | | | | | | | because the function breaks just after getting Uid data: $ cat /proc/$$/status [snip] Uid: 500 500 500 500 Gid: 500 500 500 500 [snip] $ This patch fixes this problem. Signed-off-by: Masayuki Igawa <igawa@mxs.nes.nec.co.jp> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
* Changelog v2:\"Ken'ichi Ohmichi\2009-05-082-1/+105
| | | | | | | | | | | | | | | | | | | | | | | * 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. Thanks Ken'ichi Ohmichi Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
* I have been testing a cgrulesengd daemon and I noticed it fails to\"Ken'ichi Ohmichi\2009-05-081-60/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | change the cgroup of child occasionally. I tested it by following configulation file: /etc/cgrules.conf: user01 cpuset group01/user01 % memory group01/user01 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: # cat /mnt/cgroups/cpuset/group01/user01/tasks 31801 31805 31806 # # cat /mnt/cgroups/memory/group01/user01/tasks 31801 31805 # # pstree -p 32105 sshd(31801)---sshd(31805)---bash(31806) # 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. Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
* Merge branch 'master' of ↵Balbir Singh2009-04-211-1/+3
|\ | | | | | | ssh://balbir_singh@libcg.git.sourceforge.net/gitroot/libcg
| * Fix infinite loop if receiving a NLMSG_NOOP packet.Ken'ichi Ohmichi2009-04-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. This patch fixes this problem. Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
* | Remove autogenerated files and update documentation. More documentationBalbir Singh2009-04-011-470/+0
|/ | | | | | updates will be needed and will be done in subsequent cleanups. Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
* Rework the way how so version is definedJan Safranek2009-03-261-3/+5
| | | | | | | | | Make the shared object version a bit more usable, the notation with double colons cannot be used on different places (see next patch). Also run automake && autoconf to refresh the generated stuff. Signed-off-by: Jan Safranek <jsafrane@redhat.com>
* Generate everythingautomakeJan Safranek2009-03-261-0/+468
| | | | | | Finally run autoreconf -f -i to generate all the stuff that should be generated Signed-off-by: Jan Safranek <jsafrane@redhat.com>
* Add automake makefilesJan Safranek2009-03-261-0/+6
| | | | | | | | 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. Signed-off-by: Jan Safranek <jsafrane@redhat.com>
* Distribute files to various subdirectoriesJan Safranek2009-03-262-0/+920
Signed-off-by: Jan Safranek <jsafrane@redhat.com>
generated by cgit (git 2.34.1) at 2024-06-08 11:27:36 +0000