nm-applet is calling poll() at ~10Hz

Mathieu, could you please give this a quick look and check if it is easy to fix? I suppose it should only listen to D-BUS events which shouldn't poll so often, or is it also busy-polling the soft-kill files?

So this would be mostly related to just killswitch states or something?

There was at least one case where the menu would be updated at every signal strength change, but I've already gotten rid of that as being too expensive in the last upload or so. Otherwise it's correct that the applet normally should be doing nothing but changing based on DBus messages from the NM daemon.

Sorry, I'll need to look more into it (which I've just started), but looking at the strace output like this tells me nothing at all :)

Status changed to 'Confirmed' because the bug affects multiple users.

For me this is easy to reproduce:

Just do a "killall wpa_supplicant". Network Manager will reconnect successfully (and a new wpa_supplicant process will be created) but from now on nm-applet will wake up ten times per second to poll for something that doesn't seem to be there.

I belive the poll in question is:

(gdb) where
#0 0x00007f74414c2d40 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f7441a08136 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f7441a0859a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00000000004143a7 in main ()

I see a poll with a zero timeout, followed by a failed read on an eventfd and then a 100ms poll with a timeout:

poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=9, events=POLLIN}, {fd=7, events=POLLIN}], 6, 0) = 0 (Timeout)
read(4, 0x7fffd02fb220, 16) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(3, 0x15f1ef4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=9, events=POLLIN}, {fd=7, events=POLLIN}], 6, 100) = 0 (Timeout)

The fd's are as follow:

lr-x------ 1 king king 64 Feb 27 09:04 0 -> /dev/null
l-wx------ 1 king king 64 Feb 27 09:04 1 -> /home/king/.xsession-errors
lrwx------ 1 king king 64 Feb 27 09:04 10 -> anon_inode:[eventfd]
lrwx------ 1 king king 64 Feb 27 09:04 11 -> anon_inode:[eventfd]
l-wx------ 1 king king 64 Feb 27 09:04 2 -> /home/king/.xsession-errors
lrwx------ 1 king king 64 Feb 27 09:04 3 -> socket:[13455]
lr-x------ 1 king king 64 Feb 27 09:04 4 -> anon_inode:[eventfd]
l-wx------ 1 king king 64 Feb 27 09:04 5 -> socket:[13460]
l-wx------ 1 king king 64 Feb 27 09:04 6 -> socket:[13249]
lrwx------ 1 king king 64 Feb 27 09:04 7 -> socket:[13251]
lrwx------ 1 king king 64 Feb 27 09:04 8 -> socket:[13592]
lrwx------ 1 king king 64 Feb 27 09:04 9 -> socket:[13600]

So on a clean install I was connected to the network by ethernet and nm-applet behaved w/o the 10Hz polling. I then associated the wireless and I can now see the 10Hz polling. Not sure if that is a useful data point.

Yeah, that and the above comment means it's probably something to do with how wifi gets updated; I'll dig again into that part.

So I believe I managed to trace this down to the animation functions for the applet, when a device changes state. start_animation_timeout() gets called, and somehow clear_animation_timeout() never gets called to remove the 100ms timeout once the devices are done activating.

I think this is probably some issue at the NetworkManager level rather than really in nm-applet, but I believe there's something we can do in the applet as well to mitigate such an issue.

Confirmed to be an isue in libnm-glib; reassigning to NetworkManager

This bug was fixed in the package network-manager - 0.9.2.0+git201202161854.8572ecf-0ubuntu5

---------------
network-manager (0.9.2.0+git201202161854.8572ecf-0ubuntu5) precise; urgency=low

  * debian/patches/git_libnm-glib_ensure_device_state_aef4340.patch: make sure
    we also update the device state in libnm-glib when the state-changed signal
    gets fired. (LP: #934117)
  * debian/control: update Vcs-Bzr; renamed the packaging branch.
  * debian/patches/dnsmasq-dont-read-hosts.patch: avoid dnsmasq caching old
    entries from /etc/hosts because they were listed when dnsmasq was started:
    have dnsmasq not read /etc/hosts at all, the libc resolver can properly
    take care of it on its own. (LP: #943339)
 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 01 Mar 2012 09:36:08 -0500

Thanks for fixing this!