Hide Forgot
Created attachment 502047 [details] cgroup config Description of problem: After the last libcgroup update kernel modules no longer unload, basicly this makes it impossible to cleanly reboot/halt my workstation. Version-Release number of selected component (if applicable): libcgroup-0.35.1-5.fc13.x86_64 kernel-2.6.34.8-68.fc13.x86_64 How reproducible: reboot with cgconfig and cgred on, the first service that unoad one or more modules will hang forever. Steps to Reproduce: 1. Boot with kernel flag "single" 2. unload a module 3. exec "service cgconfig start" 4. unload another module Actual results: rmmod hangs indefinitely Expected results: rmmod should exec correctly Additional info: I use cgconfig/cgrulesd as an alternative to the infamous 200 lines patch, config files are attached.
Created attachment 502048 [details] cgrulesd config
cat $CPU_CGROUP_PATH/admingroup/cpu.rt* please replace $CPU_CGROUP_PATH with whatever path you have the cpu subsystem mounted. It should most probably be at /sys/kernel/fs/cgroup/cpu
cat /cgroup/cpu/admingroup/cpu.rt* 1000000 0
ok, we are almost there, cat /etc/cgconfig.conf The reason is that rmmod needs rt privileges, and you have put it in a group without and rt runtime. So, you need to setup cgconfig to create the admingroup with some rt time. (i think 10000 should be sufficient) Dhaval
I am closing it, since its not a bug, but I can give you further instructions here itself, if you need them.
Ok, my mistake, I did not notice that that file was also available. update group admingroup { perm { task { uid = root; gid = root; } admin { uid = root; gid = root; } } cpu { cpu.shares = 384; cpu.rt_runtime_us = 10000; } } should do it for you.
TY # cat /cgroup/cpu/cpu.rt* 1000000 950000 # cat /cgroup/cpu/admingroup/cpu.rt* 1000000 950000 Problem persists, also in single user mode after only "service cgconfig start" (thus without anything assigned to the admingroup). Something else not set altogether?
I understand I need to fox things if I made a mistake, however: 1 This was not a problem before 2 Problem also occurs when nothing is assigned to a specific (possibly faulty) control group, even after "service cgconfig stop"
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.