gnome locks up with cgroup-bin installed

[Douglas Bagnall]

I installed cgroup-bin, and its dependency libcgroup1.

Over the next few boots, Network Manager failed to associate with the usual AP (which was functioning fine), and asked for the pass phrase. Whether I entered it or cancelled, I got no further response from Gnome. The mouse pointer was still mobile, but neither clicking nor keyboard shortcuts had any effect. I could however switch to virtual terminals with ctrl-alt-F[1-6], and there I tried sending increasingly blunt signals, culminating in the likes of

sudo killall -9 NetworkManager
sudo killall -9 wpa_supplicant

but not only did this not kill anything, but the killall process itself would hang and ignore ctrl-C, which disuaded me from this approach as I ran out of virtual terminals.

The problem disappeared when I uninstalled cgroup-bin. Incidentally, aptitude would also hang until I booted into single user mode.

I didn't record dmesg, but I'm attaching a sample syslog cycle. The obvious things to me are the tracebacks preceded by messages like "INFO: task gnome-panel:1944 blocked for more than 120 seconds".

I'm using karmic 32 bit x86 with the 2.6.31-22-generic kernel. All packages are up to date.

[agent 8131 (agent-8131)]

I just discovered that this was my problem as well though I am using amd64 and lucid. When cgroup-bin is installed all operations involving adding or removing modules fail (modprobe, rmmod). There may be other factors at play but for my system once installing cgroup-bin I can reproduce 100% of the time by running "sudo modprobe aes". Removing the packages fixes the problem.

[agent 8131 (agent-8131)]

I detailed some of my systems when investigating this problem here:
http://ubuntuforums.org/showthread.php?t=1518092

[Jon Bernard (jbernard)]

Hey guys, thanks for the bug report and detailed explanation, I will take a close look at this as soon as my workload eases up; In the mean time, I've prepared a PPA (ppa:jbernard/libcgroup) that contains backports of the latest stable version of libcgroup. If we could verify that this behaviour exists against the latest release, that would be a huge help. If you get a chance, try the packages in the PPA:

    https://launchpad.net/~jbernard/+archive/libcgroup/+packages

Thanks!

--
Jon

[Douglas Bagnall (douglasbagnall)]

hey Jon,

It is just the same with version 0.36.2-1~9.10prevu1_i386 of cgroup-bin and libcgroup1. The dmesg output and kern.log are attached.

I didn't install the pam module (either this time or the first time, IIRC).

(Sorry about the delay: I got sick and then I forgot).

Douglas

[Balbir Singh (bsingharora)]

I took a quick look and found all rtnl paths waiting on mutex_lock. The stuck tasks were gnome-panel, ureadahead and workqueues (modprobe, waiting on a lock).. I also found wpa_supplicant waiting on

[ 240.393172] [<c05739d5>] schedule_timeout+0x185/0x200
[ 240.393181] [<c012e7a0>] ? __wake_up_common+0x40/0x70
[ 240.393191] [<c0132f90>] ? __wake_up+0x40/0x50
[ 240.393200] [<c05736f2>] wait_for_common+0xa2/0x120
[ 240.393209] [<c013c4a0>] ? default_wake_function+0x0/0x10
[ 240.393218] [<c0573802>] wait_for_completion+0x12/0x20
[ 240.393228] [<c01568b7>] call_usermodehelper_exec+0xc7/0xd0

The rtnl_lock() is held in wext_ioctl_dispatch() (from what I can see).

Observations

1. I don't see cgroup showing up anywhere in the stack

Questions

1. What is the user mode helper? It seems like it is holding/blocking the rest of the system from making progress.

Can we please get the output of cat /proc/mounts and the cgroup filesystem output, please?

[Serge Hallyn (serge-hallyn)]

If anyone is still having this problem, can you please supply the info requested in comment #7?

[Launchpad Janitor (janitor)]

[Expired for libcgroup (Ubuntu) because there has been no activity for 60 days.]

[Douglas Bagnall (douglasbagnall)]

FWIW (i.e. not much), I replaced the originally troubled laptop when its backlight died, and my intention to provide more info foundered on a shortage of means and motivation.

[John Clarke (jrc61)]

Could this be a duplicate of https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/693594?

I had problems with "modprobe -r" hanging, and after that any attempt to do anything with modules also hung. After much testing I discovered that cgroups was to blame, and setting cpu.rt_runtime_us in the sysdefault cgroup as suggested in comment 13 in that bug fixed the problem.