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:

/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>

0 files changed, 0 insertions, 0 deletions