Hi Ivana, Ivana Varekova wrote: > I just apply the patches and try to test the result and I get segfault:
I appreciate your test and debugging. I will investigate this problem next week. Thanks Ken'ichi Ohmichi > GNU gdb (GDB) Fedora (6.8.50.20090302-21.fc11) > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i586-redhat-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > (gdb) r less cgexec.c > Starting program: /root/libcg/20090527/s/libcg/src/tools/.libs/lt-cgexec > less cgexec.c > [Thread debugging using libthread_db enabled] > > Program received signal SIGSEGV, Segmentation fault. > *__GI_strcpy (dest=0xbfffe178 "", src=0x10c <Address 0x10c out of > bounds>) at strcpy.c:39 > 39 strcpy.c: No such file or directory. > in strcpy.c > Current language: auto; currently minimal > (gdb) bt > #0 *__GI_strcpy (dest=0xbfffe178 "", src=0x10c <Address 0x10c out of > bounds>) at strcpy.c:39 > #1 0x006330e2 in cg_prepare_cgroup (cgroup=0xbfffe178, pid=17887, > dest=0x10c <Address 0x10c out of bounds>, controllers=0x110c) > at api.c:1770 > #2 0x006335a2 in cgroup_change_cgroup_path (dest=0x10c <Address 0x10c > out of bounds>, pid=17887, controllers=0x110c) at api.c:2041 > #3 0x006334c7 in cgroup_change_cgroup_uid_gid_flags (uid=0, gid=0, > pid=17887, flags=0) at api.c:1988 > #4 0x00633535 in cgroup_change_cgroup_uid_gid (uid=0, gid=0, pid=17887) > at api.c:2020 > #5 0x08048bfc in main (argc=3, argv=0xbffff624) at cgexec.c:109 > (gdb) > > > > Dhaval Giani wrote: >> On Wed, May 27, 2009 at 04:37:18PM +0900, 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 ? >>> >> Quite complicated actually. What this would mean is that we would also >> need some tool which could write the config files out. I am not sure if >> this is the way we want to proceed forward in. >> >> >>> 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 ;) >>> >>> >> True, but I think we need to keep the configuration file as simple as >> possible for it to be useful. >> >> Thanks, >> > > > > ------------------------------------------------------------------------------ > 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
