#45 cgrules user:process syntax

open
Dhaval Giani
None
5
2009-12-10
2009-12-09
remche
No

Hi,
I face a strange behavior with the cgrules.conf file : it seems that the syntax
user: process controllers destination
does not work : when I specify a process, by name or by path, it never falls to the good cgroup. Is there a know isssue about this ?
I use the 0.34-2 debian package from sid.
Thx,
remi

Discussion

  • Dhaval Giani
    Dhaval Giani
    2009-12-10

    Can I see your config file please? My guess is that the ordering in the file is not correct.

     
  • Dhaval Giani
    Dhaval Giani
    2009-12-10

    • assigned_to: nobody --> dhaval_giani
     
  • remche
    remche
    2009-12-11

    Hi,
    Here are the simplest files which do not work :

    /etc/cgconfig.conf

    mount {
    cpuset = /dev/cgroups/cpuset;
    }

    group ssh {
    cpuset {
    cpuset.cpus = 0;
    cpuset.mems = 0;
    }
    }

    /etc/cgrules.conf
    @calcul:sshd cpuset ssh/

    Another thing, yesterday I had a kernel panic on a cluster node while rebooting it. I need to update-rc.d remove the daemons cgconfig and cgrules to boot (and remove the cgroup pam directive...).
    I use the 0.34-2 from sid with a 2.6.26-2 -amd64 from lenny. Must I post another ticket ?

    Thx in advance,
    rémi

     
  • Dhaval Giani
    Dhaval Giani
    2009-12-11

    I would like to see the panic trace. If it is cgroups related, we will need to post it to the corresponding bug reporting system (if it is an upstream kernel, then the upstream lists, else the debian bugzilla). (even otherwise it will need to be reported)

     
  • remche
    remche
    2009-12-11

    Sorry, but I can't reproduce the panic : it is production server. but I cant paste the /var/log/messages, hoping it helps.
    I will try to reproduce it next week with a clean debian install.

    [...]
    Dec 10 16:56:11 r0calcul8 CGRE[5470]: Started the CGroup Rules Engine Daemon.
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] Modules linked in: rfcomm l2cap bluetooth battery nfs lockd nfs_acl sunrpc ppdev parpor
    t_pc lp parport ipv6 acpi_cpufreq cpufreq_userspace cpufreq_conservative cpufreq_ondemand cpufreq_powersave cpufreq_stats freq_table sg
    sr_mod cdrom loop psmouse tpm_infineon tpm i2c_i801 serio_raw tpm_bios i2c_core button rng_core pcspkr shpchp pci_hotplug evdev ext3 jbd
    mbcache usb_storage ata_generic ide_pci_generic usbhid hid ff_memless ses enclosure sd_mod ahci libata piix dock ide_core ehci_hcd uhci
    _hcd aacraid scsi_mod e1000e thermal processor fan thermal_sys [last unloaded: scsi_wait_scan]
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] CPU 15:
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] Modules linked in: rfcomm l2cap bluetooth battery nfs lockd nfs_acl sunrpc ppdev parport_pc lp parport ipv6 acpi_cpufreq cpufreq_userspace cpufreq_conservative cpufreq_ondemand cpufreq_powersave cpufreq_stats freq_table sg sr_mod cdrom loop psmouse tpm_infineon tpm i2c_i801 serio_raw tpm_bios i2c_core button rng_core pcspkr shpchp pci_hotplug evdev ext3 jbd mbcache usb_storage ata_generic ide_pci_generic usbhid hid ff_memless ses enclosure sd_mod ahci libata piix dock ide_core ehci_hcd uhci_hcd aacraid scsi_mod e1000e thermal processor fan thermal_sys [last unloaded: scsi_wait_scan]
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] Pid: 5490, comm: kstopmachine Not tainted 2.6.26-2-amd64 #1
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] RIP: 0010:[<ffffffff8042a3d7>] [<ffffffff8042a3d7>] _spin_lock_irqsave+0x0/0x30
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] RSP: 0018:ffff81081a531e48 EFLAGS: 00000246
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] RAX: 000000000000000f RBX: ffff81081a531e70 RCX: ffff8108185a35b0
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] RDX: ffff8108185a3670 RSI: 0000000000000001 RDI: ffff8100010d2880
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] RBP: ffffffff8021a827 R08: 0000000000000000 R09: ffff8100010d2880
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] R10: ffff810080af5000 R11: ffffffff8021a827 R12: ffff81081a531e70
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] R13: 7fffffffffffffff R14: ffff81081a531dc8 R15: ffffe2001c5b2a00
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] FS: 0000000000000000(0000) GS:ffff81081cff4840(0000) knlGS:0000000000000000
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] CR2: 00007fa05770c315 CR3: 0000000000201000 CR4: 00000000000006e0
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744]
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] Call Trace:
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] [<ffffffff8022f074>] ? hrtick_set+0x4a/0xf7
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] [<ffffffff80428faf>] ? thread_return+0x6b/0xac
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] [<ffffffff8021a827>] ? lapic_next_event+0x0/0x13
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] [<ffffffff80230730>] ? sys_sched_yield+0x46/0x4c
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] [<ffffffff80262829>] ? stopmachine+0x78/0xa3
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] [<ffffffff802301c9>] ? schedule_tail+0x27/0x5c
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] [<ffffffff8020cf28>] ? child_rip+0xa/0x12
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] [<ffffffff802627b1>] ? stopmachine+0x0/0xa3
    Dec 10 16:57:11 r0calcul8 kernel: [ 1649.269744] [<ffffffff8020cf1e>] ? child_rip+0x0/0x12

     
  • Dhaval Giani
    Dhaval Giani
    2009-12-12

    The kernel panic is not caused by cgroups. Also 2.6.26 based kernels are rather old (almost 2 yrs). You should report this panic to your distro.

    The libcgroup issue we will continue discussing here and resolve.

     
  • Hi,

    I tested remche's configuration files on the latest libcgroup (commit 5dfd5d40b68febd5376e6823021e4b376de77efc), and it worked correctly.
    Could you please check the status of service "cgred" by `service cgred status` ?

    Here is the test log on my machine:

    [root@localhost ~]# cat /etc/cgrules.conf
    @calcul:sshd cpuset ssh/

    [root@localhost ~]# cat /etc/cgconfig.conf
    mount {
    cpuset = /dev/cgroups/cpuset;
    }

    group ssh {
    cpuset {
    cpuset.cpus = 0;
    cpuset.mems = 0;
    }
    }

    [root@localhost ~]# service cgconfig start
    Starting cgconfig service: [ OK ]
    [root@localhost ~]# service cgred start
    Starting CGroup Rules Engine Daemon...
    [ OK ]
    [root@localhost ~]#

    A user "calcul" loged in the machine by ssh.

    [root@localhost ~]# cat /dev/cgroups/cpuset/ssh/tasks
    13148
    13152
    13153
    [root@localhost ~]#

    [calcul@localhost ~]$ pstree -np 13148
    sshd(13148)───sshd(13152)───bash(13153)───pstree(13196)
    [calcul@localhost ~]$

     
  • Dhaval Giani
    Dhaval Giani
    2009-12-18

    remche, could you please test against the latest git. To do so, you need to have git installed, and you shold do a

    git clone git://libcg.git.sourceforge.net/gitroot/libcg/libcg

    This will get you the latest codebase, install it and test again.