[Lxc-users] Problem with cgroup with LXc

[Daniel Lezcano]

On 10/26/2010 08:38 AM, Miroslav Lednicky, AVONET, s.r.o. wrote:
> Hello all,
>
> 	I started using LXCs. They are very nice.
> But I have problems with cgroup.
>
> There are problem with remove old informations from cgroup subdirectory.
> It happend only sometimes. Typicaly zabbix agent in LXC can generate
> this problem. But not always.
>
> Please see:
>
> ls -l /cgroup/test_lxc
>
> drwxr-xr-x 3 root root 0 2010-09-29 23:07 10194
> drwxr-xr-x 3 root root 0 2010-10-01 21:11 11382
> drwxr-xr-x 3 root root 0 2010-10-03 18:29 12632
> drwxr-xr-x 3 root root 0 2010-09-15 15:10 1715
> drwxr-xr-x 3 root root 0 2010-10-15 07:31 20270
> drwxr-xr-x 3 root root 0 2010-10-16 02:05 20468
> drwxr-xr-x 3 root root 0 2010-10-16 22:42 21090
> drwxr-xr-x 3 root root 0 2010-10-19 04:58 22349
> drwxr-xr-x 3 root root 0 2010-08-27 16:09 22455
> drwxr-xr-x 3 root root 0 2010-08-29 10:45 23636
> drwxr-xr-x 3 root root 0 2010-09-16 19:10 2398
> drwxr-xr-x 3 root root 0 2010-10-22 00:27 24182
> drwxr-xr-x 3 root root 0 2010-10-26 06:45 27044
> drwxr-xr-x 3 root root 0 2010-09-04 18:26 27119
> drwxr-xr-x 3 root root 0 2010-09-05 04:24 27187
> drwxr-xr-x 3 root root 0 2010-09-09 21:39 30581
> drwxr-xr-x 3 root root 0 2010-09-20 10:10 4793
> -r--r--r-- 1 root root 0 2010-08-02 13:53 cgroup.procs
> -r--r--r-- 1 root root 0 2010-08-02 13:53 cpuacct.stat
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpuacct.usage
> -r--r--r-- 1 root root 0 2010-08-02 13:53 cpuacct.usage_percpu
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpu.rt_period_us
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpu.rt_runtime_us
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpuset.cpu_exclusive
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpuset.cpus
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpuset.mem_exclusive
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpuset.mem_hardwall
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpuset.memory_migrate
> -r--r--r-- 1 root root 0 2010-08-02 13:53 cpuset.memory_pressure
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpuset.memory_spread_page
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpuset.memory_spread_slab
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpuset.mems
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpuset.sched_load_balance
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpuset.sched_relax_domain_level
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 cpu.shares
> --w------- 1 root root 0 2010-08-02 13:53 devices.allow
> --w------- 1 root root 0 2010-08-02 13:53 devices.deny
> -r--r--r-- 1 root root 0 2010-08-02 13:53 devices.list
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 freezer.state
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 memory.failcnt
> --w------- 1 root root 0 2010-08-02 13:53 memory.force_empty
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 memory.limit_in_bytes
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 memory.max_usage_in_bytes
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 memory.memsw.failcnt
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 memory.memsw.limit_in_bytes
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 memory.memsw.max_usage_in_bytes
> -r--r--r-- 1 root root 0 2010-08-02 13:53 memory.memsw.usage_in_bytes
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 memory.soft_limit_in_bytes
> -r--r--r-- 1 root root 0 2010-08-02 13:53 memory.stat
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 memory.swappiness
> -r--r--r-- 1 root root 0 2010-08-02 13:53 memory.usage_in_bytes
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 memory.use_hierarchy
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 net_cls.classid
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 notify_on_release
> -rw-r--r-- 1 root root 0 2010-08-02 13:53 tasks
>
> ls -R1 10194
> 10194:
> 2
> cgroup.procs
> cpuacct.stat
> cpuacct.usage
> cpuacct.usage_percpu
> cpu.rt_period_us
> cpu.rt_runtime_us
> cpuset.cpu_exclusive
> cpuset.cpus
> cpuset.mem_exclusive
> cpuset.mem_hardwall
> cpuset.memory_migrate
> cpuset.memory_pressure
> cpuset.memory_spread_page
> cpuset.memory_spread_slab
> cpuset.mems
> cpuset.sched_load_balance
> cpuset.sched_relax_domain_level
> cpu.shares
> devices.allow
> devices.deny
> devices.list
> freezer.state
> memory.failcnt
> memory.force_empty
> memory.limit_in_bytes
> memory.max_usage_in_bytes
> memory.memsw.failcnt
> memory.memsw.limit_in_bytes
> memory.memsw.max_usage_in_bytes
> memory.memsw.usage_in_bytes
> memory.soft_limit_in_bytes
> memory.stat
> memory.swappiness
> memory.usage_in_bytes
> memory.use_hierarchy
> net_cls.classid
> notify_on_release
> tasks
>
> 10194/2:
> cgroup.procs
> cpuacct.stat
> cpuacct.usage
> cpuacct.usage_percpu
> cpu.rt_period_us
> cpu.rt_runtime_us
> cpuset.cpu_exclusive
> cpuset.cpus
> cpuset.mem_exclusive
> cpuset.mem_hardwall
> cpuset.memory_migrate
> cpuset.memory_pressure
> cpuset.memory_spread_page
> cpuset.memory_spread_slab
> cpuset.mems
> cpuset.sched_load_balance
> cpuset.sched_relax_domain_level
> cpu.shares
> devices.allow
> devices.deny
> devices.list
> freezer.state
> memory.failcnt
> memory.force_empty
> memory.limit_in_bytes
> memory.max_usage_in_bytes
> memory.memsw.failcnt
> memory.memsw.limit_in_bytes
> memory.memsw.max_usage_in_bytes
> memory.memsw.usage_in_bytes
> memory.soft_limit_in_bytes
> memory.stat
> memory.swappiness
> memory.usage_in_bytes
> memory.use_hierarchy
> net_cls.classid
> notify_on_release
> tasks
>
> It looks like as this problem:
>
> http://www.mail-archive.com/devel@openvz.org/msg19736.html
>
> But I have no solution.
>
> Can somebody help me?
>
> It is big problem with lxc-stop and lx-start. I must restarting server.
>    

Weird.

Is it possible the zabbix application creates a new namespace ? If it is 
the case, it's a known problem with the ns_cgroup, that has been solved 
for the next kernel release because the ns_cgroup won't be used anymore, 
so you the application can unshare whatever they want.

Also, is it possible, you didn't pay attention and you tried to launch a 
container inside a container ?

Thanks
      -- Daniel