KAMEZAWA Hiroyuki wrote:
> On Wed, 27 May 2009 16:06:03 +0900
> "Ken'ichi Ohmichi" <[email protected]> wrote:
>
>   
>> Hi,
>>
>> KAMEZAWA Hiroyuki wrote:
>>     
>>>>>>> This patchset adds a new rule based on process name.
>>>>>>> I have some TODOS, so this patchset is not complete.
>>>>>>> I'd like to talk about them, any comment is welcome.
>>>>>>>
>>>>>>> TODOS:
>>>>>>> ======
>>>>>>> * 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.
>>>>>>>
>>>>>>> * Think about the length of process name.
>>>>>>>   A process name is taken from /proc/<pid>/status file, and the name
>>>>>>>   is shortened to 15 characters if the real name is over than 16
>>>>>>>   characters. That is a linux kernel's behavior. Should we consider
>>>>>>>   a process name in /etc/cgrules.conf as 15 characters, if it is over
>>>>>>>   than 16 characters like a linux kernel ?
>>>>>>>
>>>>>>>               
>>>>>> I'm sorry that I don't read the whole patch precisely.
>>>>>>
>>>>>> Why based on "process name", why not "exec file" ?
>>>>>> Do you have special reason ?
>>>>>>             
>>>>> One disadvantage of exe file I can think of is "script" file.
>>>>> But /proc/xxx/status's information is too naive.
>>>>>
>>>>> Can't you parse /proc/xxx/cmdline file and check "what's really executed 
>>>>> ?"
>>>>> Parser can be very difficult ?
>>>>>           
>>>> Good point. We can parse /proc/xxx/cmdline instead of /proc/xxx/status
>>>> for getting a process name, and that is better than current patch.
>>>> But I have one concern. The /proc/xxx/cmdline file of a kernel thread is
>>>> empty, and we cannot get the name from the file.
>>>> How about getting a process name from a /proc/xxx/status file only if
>>>> /proc/xxx/cmdline is empty ?
>>>>
>>>>         
>>> Maybe good. For example, "ps" does [kthread] for tasks with empty cmdline.
>>>
>>> But, IIUC, a script like
>>>
>>> %./myscript.sh
>>>
>>> has cmdline as /bin/bash ./myscript.sh and "status" file includes 
>>> "myscript.sh"
>>> So, there may be 3 ways for specifing a task by name.
>>>
>>> exe:/bin/bash         # full-path name of executable file (but can't handle 
>>> scripts)
>>> comm:myscript.sh      # name of executable file
>>> cmdline:/bin/bash myscript.sh # cmdline
>>>
>>> Then, having "exe" and "comm" is maybe good....maybe.
>>>       
>> I guess you means the following, right ?
>>
>> * libcgroup should distinguish "exec file" or "script file" of each
>>   process automatically.
>>
>> * If "exec file", the first arg in /proc/<pid>/cmdline is checked.
>>   In your example, the first arg means /bin/bash.
>>
>> * If "script file", the item of "Name:" in /proc/<pid>/status is checked.
>>   In your example, the item means myscript.sh.
>>
>>     
> I have no objections if we have clear rule.
> If I was you, I'll write following logic.
>
> NEW)      <user>:(<ops>=):<process name>  <controllers>   <destination>
>
> ops can be "exe", "comm", "cmdline"
>
>      exe=/bin/bash
> or
>      comm=myscript.sh
> or
>      cmdline="/bin/bash /home/kamezawa/bin/myscript.sh"
>
> Complicated ?
> I have no strong opinion but I feel only "comm" can be too short for
> enterprise users. I saw 3 version of "java" runs under different applications
> in user's environment, all uid were "root". (oh, yes, seems crazy ;)
>
>   
Hello,
I just look to /proc/<pid>/environ
and the last value "_" could be useful for this purpose too - there 
seems to be name with full path - but I have not study it more now - I 
try to find the precise meaning.
Ivana Hutarova Varekova
> Thanks,
> -Kame
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Libcg-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/libcg-devel
>   


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Libcg-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libcg-devel

Reply via email to