On Wed, 27 May 2009 10:37:20 +0200
Ivana Varekova <[email protected]> wrote:

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

IIUC, it's bash's enviroment vaiable.
== man bash ==
       _      At shell startup, set to the absolute pathname  used  to  invoke
              the  shell or shell script being executed as passed in the envi-
              ronment or argument list.  Subsequently,  expands  to  the  last
              argument  to the previous command, after expansion.  Also set to
              the full pathname used  to  invoke  each  command  executed  and
              placed in the environment exported to that command.  When check-
              ing mail, this parameter holds the name of the  mail  file  cur-
              rently being checked.

"Also set to the full pathname used  to  invoke  each  command  executed  and
 placed in the environment exported to that command."


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

Reply via email to