Do you have any debug logs with traces of what cgred is doing? My best
guess is cgred will need to be enhanced, feel free to send a patch
Balbir Singh
On Mon, Sep 29, 2014 at 4:22 PM, Weng Meiling
<wengmeiling.w...@huawei.com> wrote:
> On 2014/9/29 17:28, Balbir Singh wrote:
>> Hi,
>>
>> Are you applying the policy after task creation - looks like it! cgred
>> should handle it, some newer version support cgroups.procs along with
>> cgroups.tasks. Do you have a debug trace of cgred (strace/ltrace)?
>>
>> Balbir Singh
>>
>
> Thanks for fast reply!
>
> yes, we restart cgred after task creation. you said some newer version
> support cgroups.procs along with
> cgroups.tasks. I can't pull the libcg git repository, but review the code
> from web, it seems that the
> newest version only one interface cgroup_get_procs() to get the task group id
> contained in cgroups.procs,
> but this is not enough fot the situation mentioned in former mail, am I
> missing something?
>
> We used cgred in debug mode, and found the running threads which match the
> rules could not
> be controlled by cgred.
>
> Thanks!
> Weng Meiling
>
>> On Mon, Sep 29, 2014 at 11:47 AM, Weng Meiling
>> <wengmeiling.w...@huawei.com> wrote:
>>> Hi, what do you think about this situation?
>>>
>>> Thanks!
>>> Weng Meiling
>>>
>>> On 2014/9/24 9:02, Weng Meiling wrote:
>>>> ping...
>>>>
>>>> On 2014/9/22 17:32, Weng Meiling wrote:
>>>>> On 2014/9/20 17:13, Weng Meiling wrote:
>>>>>> Hi guys,
>>>>>> In our environment, we found the following problem:
>>>>>>
>>>>>> we have a process and it has some threads with the same name:
>>>>>>
>>>>>> # ps -L -eo comm,pid,lwp,args,start |grep Test
>>>>>> Testd 4489 4489 /usr/bin/Testd 09:03:39
>>>>>> Testd 4489 4582 /usr/bin/Testd 09:03:39
>>>>>> Testd 4489 4584 /usr/bin/Testd 09:03:39
>>>>>> Testd 4489 4585 /usr/bin/Testd 09:03:39
>>>>>> Testd 4489 4587 /usr/bin/Testd 09:03:39
>>>>>>
>>>>>>
>>>>>> the cgrule is:
>>>>>>
>>>>>> *:Testd cpu,memory,cpuset test
>>>>>>
>>>>>> if the Testd has been running, and then restart or start cgred service,
>>>>>> just the process
>>>>>> 4489 will move into test cgroup, but the other threads just leave in the
>>>>>> root cgroup,
>>>>>> the reason seems that cgred just move running processes according /proc,
>>>>>> but thread isn't
>>>>>> listed under /proc, should not cgred deal with this situation?
>>>>>>
>>>>>
>>>>> The following patch maybe can deal with this situation, another way to
>>>>> deal with this situation is
>>>>> to use cgroup.procs file then tasks in cgroup_attach_task_pid() according
>>>>> to some conditions,
>>>>> but this need to modify many apis, so I think the following patch is more
>>>>> suitable, just modify one
>>>>> api. What do you think about this?
>>>>>
>>>>> Subject: [PATCH] cgred: cgred should deal with threads when starts
>>>>>
>>>>> Signed-off-by: Weng Meiling <wengmeiling.w...@huawei.com>
>>>>> ---
>>>>> src/api.c | 44 ++++++++++++++++++++++++++++++++------------
>>>>> 1 file changed, 32 insertions(+), 12 deletions(-)
>>>>>
>>>>> diff --git a/src/api.c b/src/api.c
>>>>> index 8106eff..951cafb 100644
>>>>> --- a/src/api.c
>>>>> +++ b/src/api.c
>>>>> @@ -3189,25 +3189,45 @@ int cgroup_change_all_cgroups(void)
>>>>>
>>>>> while ((pid_dir = readdir(dir)) != NULL) {
>>>>> int err, pid;
>>>>> - uid_t euid;
>>>>> - gid_t egid;
>>>>> - char *procname = NULL;
>>>>> + DIR *subdir;
>>>>> + struct dirent *subpid_dir = NULL;
>>>>> + char subpath[FILENAME_MAX];
>>>>>
>>>>> err = sscanf(pid_dir->d_name, "%i", &pid);
>>>>> if (err < 1)
>>>>> continue;
>>>>>
>>>>> - err = cgroup_get_uid_gid_from_procfs(pid, &euid, &egid);
>>>>> - if (err)
>>>>> - continue;
>>>>> + /* sscanf the task directory to deal with threads */
>>>>> + memset(subpath, 0, FILENAME_MAX);
>>>>> + sprintf(subpath, "/proc/%d/task", pid);
>>>>> + subdir = opendir(subpath);
>>>>> + if (!subdir) {
>>>>> + closedir(dir);
>>>>> + return -ECGOTHER;
>>>>> + }
>>>>>
>>>>> - err = cgroup_get_procname_from_procfs(pid, &procname);
>>>>> - if (err)
>>>>> - continue;
>>>>> + while ((subpid_dir = readdir(subdir)) != NULL) {
>>>>> + int subpid;
>>>>> + gid_t egid;
>>>>> + uid_t euid;
>>>>> + char *procname = NULL;
>>>>> + err = sscanf(subpid_dir->d_name, "%i", &subpid);
>>>>> + if (err < 1)
>>>>> + continue;
>>>>>
>>>>> - err = cgroup_change_cgroup_flags(euid, egid, procname, pid,
>>>>> 0);
>>>>> - if (err)
>>>>> - cgroup_dbg("cgroup change pid %i failed\n", pid);
>>>>> + err = cgroup_get_uid_gid_from_procfs(subpid, &euid,
>>>>> &egid);
>>>>> + if (err)
>>>>> + continue;
>>>>> +
>>>>> + err = cgroup_get_procname_from_procfs(subpid,
>>>>> &procname);
>>>>> + if (err)
>>>>> + continue;
>>>>> +
>>>>> + err = cgroup_change_cgroup_flags(euid, egid,
>>>>> procname, subpid, 0);
>>>>> + if (err)
>>>>> + cgroup_dbg("cgroup change pid %i failed\n",
>>>>> subpid);
>>>>> + }
>>>>> + closedir(subdir);
>>>>> }
>>>>>
>>>>> closedir(dir);
>>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Slashdot TV. Videos for Nerds. Stuff that Matters.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Libcg-devel mailing list
>>> Libcg-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/libcg-devel
>>
>> .
>>
>
>
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Libcg-devel mailing list
Libcg-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libcg-devel
