Comment 5 for bug 825897

Revision history for this message
Tristan Schmelcher (tschmelcher) wrote : Re: network-manager becomes unresponsive, requiring a service restart

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 ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007fe0256b3e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007fe024a544bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#7 0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7fe0177b1700 (LWP 6246)):
#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 0x00007fe0264ae2c6 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4 0x00007fe024faf9a5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007fe0256b3e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007fe024a544bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#7 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7fe027a82980 (LWP 6244)):
#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 0x0000000000414267 in main (argc=1, argv=0x7fff28c08c18) at main.c:106

Also no different, so there does not seem to be any obvious hang in the nm-applet process.

Curiously, when this happened today I found that Update Manager was open with 3 updates available, and it was also unresponsive--clicking on it in the launcher did not display the window and I also could not Alt+Tab to it. gdb showed no obvious hangs in the update-manager Python process either. Could be related (but not the root cause, since running Update Manager manually did not repro the problem).