nm-applet becomes unresponsive, requiring a restart

Bug #825897 reported by Jamin W. Collins on 2011-08-13
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Network Manager Applet
New
Medium
network-manager-applet (Ubuntu)
Undecided
Unassigned

Bug Description

After nm-applet has been running for a while (overnight) it becomes unresponsive:
- unable to uncheck "Enable Wireless"
- doesn't list the numerous additional networks under "More Networks"
- doesn't find new networks

This behavior persists until the applet is restarted via something like:
killall nm-applet; sleep 1; nohup nm-applet &

This problem has been consistently present since 11.04

Jamin W. Collins (jcollins) wrote :
Changed in network-manager (Ubuntu):
status: New → Confirmed

I think I'm experiencing the same issue. After running overnight, the NM applet becomes unresponsive--clicking on any menu item does nothing, and the submenus are empty. I tried restarting the network-manager service once but it did not fix the problem--I had to also kill and restart nm-applet. I'm using 11.04 amd64 on a brand-new System76 Serval Professional.

Interestingly, this bug doesn't happen on any of my other computers, all of which are also running 11.04 amd64. This computer is also the only computer I have with 802.11n support (Centrino Advanced-N 6230 rev 34), which I am using with a Netgear WNDR3700v2 router. Looking at Jamin's NetDevice.wlan0.txt file, he has 802.11n support too.

Perhaps this is a bug in NetworkManager's 802.11n support or in a 802.11n driver?

affects: network-manager (Ubuntu) → network-manager-applet (Ubuntu)

I don't see how this could be a dupe of bug #684599. That was marked as fixed in Natty on 2011-02-04, whereas Jamin and I are seeing this issue in Natty now. If this were a dupe of #684599, the problem would already be fixed for us.

I continue to experience this in 12.04. I am unduping since the symptoms and chronology of this bug bear no resemblance to bug 684599.

Download full text (4.8 KiB)

Some more information:

I can repro this 100% of the time by enabling wireless, connecting to my 802.11n router, disconnecting from the wired network, and leaving the computer on for a long time. 1 day seems to be sufficient. After that, the NM applet becomes unresponsive--clicking on any menu item does nothing, and the submenus are empty. OTOH, the wireless connection continues to work.

Killing and restarting nm-applet fixes the problem. There seems to be no need to restart the network-manager service.

In my "normal" day-to-day activities I leave wireless disabled and I leave the computer in sleep mode most of the time, which does NOT repro this.

Memory usage of nm-applet in top while unresponsive:

 1980 tristan 20 0 624m 23m 12m S 0 0.3 1:02.16 nm-applet

Backtrace of all threads in nm-applet while unresponsive:

(gdb) thread apply all bt

Thread 3 (Thread 0x7f2ada61d700 (LWP 1986)):
#0 0x00007f2ae1eddb03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f2ae2422ff6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f2ae242345a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f2adae5e98b in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4 0x00007f2ae24449a5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f2ae2b48e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f2ae1ee94bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#7 0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7f2ad8dab700 (LWP 1991)):
#0 0x00007f2ae1eddb03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f2ae2422ff6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f2ae242345a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f2ae39432c6 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4 0x00007f2ae24449a5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f2ae2b48e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f2ae1ee94bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#7 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f2ae4f17980 (LWP 1980)):
#0 0x00007f2ae1eddb03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f2ae2422ff6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f2ae242345a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x0000000000414267 in main (argc=1, argv=0x7fffc4aac088) at main.c:106

Memory usage of nm-applet in top after restarting it:

 6244 tristan 20 0 618m 17m 11m S 0 0.2 0:00.33 nm-applet

Almost identical numbers, so clearly the bug has nothing to do with leaks in nm-applet.

Backtrace of all threads in nm-applet after restarting it:

(gdb) thread apply all bt

Thread 3 (Thread 0x7fe01d188700 (LWP 6245)):
#0 0x00007fe024a48b03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007fe024f8dff6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007fe024f8e45a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007fe01d9c998b in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4 0x00007fe024faf9a5 in...

Read more...

As a test I left my computer connected to both wired _and_ wireless, and that also repro'ed the bug after 1 day.

Update Manager was open with 4 updates, but it was working properly, so probably the Update Manager hang before was unrelated.

Interestingly, physically disconnecting the wired network while the applet was unresponsive _did_ correctly update the applet state, so it wasn't totally hung. But the sub-menus continued to be empty and clicking on anything in the main applet menu continued to be ignored.

As another test I left my computer connected to only wired, but that did _not_ repro the bug after 1 day. So it seems that having a wireless connection is a requirement.

Also repros with 802.11n disabled via:

sudo rmmod iwlwifi
sudo modprobe iwlwifi 11n_disable=1

So apparently not related to 802.11n as I thought.

Still repros in 12.10. Also repros in a LiveCD environment, so it's not something with my install.

My computer is a System76 Leopard Extreme. I opened a System76 service request but their technicians cannot reproduce the problem with their hardware.

My girlfriend recently got a Dell XPS 13 Developer Edition and it also experiences the problem. Interestingly, it has a similar wireless adapter model (Centrino Advanced-N 6235 rev 24). I am thinking that there may be a compatibility problem between Ubuntu, the Centrino Advanced-N 6230/6235, and something in my environment. Perhaps it doesn't like my wireless router (WNDR3700v2) or the fact that there are about three dozen wireless networks in range.

As another test, I disabled my wireless router itself while the problem was reproing. Much like when I tested unplugging a wired cable, nm-applet showed that it had been disconnected from the wireless and that it was trying to reconnect, but the applet was still unresponsive to user input. As before, killing and restarting nm-applet made it work properly again.

Jamin W. Collins (jcollins) wrote :

All that is necessary to reproduce this bug is lots of changes in the wireless networks seen by the system. Nothing more.

Jamin W. Collins (jcollins) wrote :

Should also be noted that simply killing nm-applet and restarting it are sufficient to restore functionality:

killall nm-applet; sleep 1; nohup nm-applet &

Changed in network-manager-applet:
importance: Unknown → Medium
status: Unknown → New
summary: - network-manager becomes unresponsive, requiring a service restart
+ nm-applet becomes unresponsive, requiring a restart
description: updated
jdblair (jdb) wrote :

I can confirm the symptoms and the workaround. I'm running and up-to-date 12.04.

I don't know if this is relevant: I frequently change network types, switching between static ethernet, dhcp ethernet, dhcp wifi on multiple networks, and ip over bluetooth.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.