nm-applet vanished, disappears from tray

Bug #43379 reported by Christian Holtje on 2006-05-07
This bug affects 18 people
Affects Status Importance Assigned to Milestone
network-manager (Arch Linux)
network-manager (Ubuntu)
network-manager-applet (Ubuntu)

Bug Description

There are two known reasons why nm-applet can disappear from system tray:
 1. network-manager-applet crashes by itself
 2. network-manager becomes unavailable (aka it crashes).

Please don't post additional information and logs to this bug if you experience any of the two cases above ... and file a *new* bug against the packages.

So when nm-applet has disappeared, check whether
 1. ps -eaf | grep nm-applet
 2. ps -eaf | grep NetworkManager | grep -v NetworkManagerDispatcher

yield any results. If nm-applet isn't running, file a bug against network-manager-applet package; in case NetworkManager isn't running, please file a bug against network-manager and attach your daemon.log/syslog.
We (the bug triagers) will then try to find the appropriate duplicate and ask for more info if needed.

----------- Original Summary

Binary package hint: network-manager-gnome

The Actors:
  Fire -- the stalwart DHCP server running Debian Stable (Sarge)
  Dib -- the noble laptop and DHCP client, possessing a heart of gold
  and an instance of nm-applet. Dib runs the latest Dapper (May 5th
  2006) running nm-applet version 0.6.2-0ubuntu5.
  Christian -- the mad scientist

The Scene:
  A dark and stormy night.
  Fire has already given Dib a dynamic IP addressed based on his wifi
  MAC address.
  Christian wants to make Dib's IP static when Dib is connected via wifi.

What Happened:
  Christian, sitting at his laptop, Dib, starts to edit the Fire's
  DHCPd configuration remotely via SSH. He sets Dib's wifi MAC
  address to return the same IP as the wired MAC does.

  Christian restarts the DHCP server. The next time Dib asks the DHCP
  server what it's IP address is, it will change from .189 to .16

  A few minutes later, Dib sends the DHCP request. All the SSH
  connections freeze (as expected) and the nm-applet shows its
  reconnecting to the network. As nm-applet gets to the end of its
  reconnect cycle, when it should have shown the wifi bars again, it

  Christian confirms that nm-applet is still running. Christian tries
  to restart nm-applet, but to no avail... Christian checks the
  network, it is correctly configured, but nm-applet has lost its

  A complete reboot is required to make nm-applet work again.

What was Expected:
  It should have "Just Worked".

  nm-applet or network-manager didn't deal very well with the same
  network connection handing out a new IP address, even though this is
  acceptable DHCP behavior.

  Also, Christian gets into strange moods at time and submits bug
  reports with a bizarre sense of humor. But at least the reports are

Jeff Johnson (jeff-comfrey) wrote :

i am also not seeing an icon on nm-applet. the systray gets bumped a bit to the right... but no icons are appearing.

rfonteyn (roel-fonteyn) wrote :


I move a lot with my portable. Switching from wired to wireless to wired to another wired etc.....

Although nm-applet still seems to work, it most of the time vanishes from the systray after the second or third network switch (not actually counted this number), leaving me whitout any option to manually choose which network to connect to.

Only reboot brings it back on the tray.

Changed in network-manager:
status: Unconfirmed → Confirmed

I have a very similar issue. I get the following behaviour:

kernel 2.6.15-23-amd64-k8: nm-applet works as it should (modulo some minor annoyances)

any later kernel: nm-applet never appears in the tray. If I kill it and restart it, I see the other tray icons move around a bit, but the nm-applet icon never appears.

I'm using the bcm43xx driver, maybe this behaviour is related to some changes in the driver between kernel versions?

As per Robert Love's suggestion in http://bugzilla.gnome.org/show_bug.cgi?id=341320, I tried doing "sudo NetworkManager --no-daemon" and lo and behold, the nm-applet icon appears again. Now the mystery has shifted to why the daemon crashes in the first place.

(and also why n-m thinks my Broadcom 4309 is a wired interface, but that's a different bug).

To get a visible nm-applet that doesn't think my wireless card is wired, I need to do the following:

sudo killall hald
sudo -u haldaemon hald
sudo NetworkManager

Scott Robinson (scott-ubuntu) wrote :

Might I recommend the much more polite and proper:

sudo /etc/dbus-1/event.d/25NetworkManager restart
sudo /etc/dbus-1/event.d/26NetworkManagerDispatcher restart

This is more future proof.

Alex Mauer (hawke) wrote :

The tray icon also vanishes (or rather, never appears) when bug #58165 (in libpam-foreground) is in effect. This may or may not be related to this one. Either way, I would think that (part of) the solution is to have nm-applet create the applet independent of communication with NetworkManager.

Lionel Dricot (ploum) wrote :

I confirm this bug. Personnaly, the way to reproduce it nearly all the time is to select another wireless network when n-m is connecting to one given wifi and that the two dots are already green.

Ante Karamatić (ivoks) wrote :

It doesn't work for me in last 4-5 boots (while it worked OK after install) on Feisty. In syslog one can see:

NetworkManager: <information>^IActivation (eth1) Stage 2 of 5 (Device Configure) starting...
NetworkManager: file nm-device-802-11-wireless.c: line 2071 (ap_need_key): assertion failed: (security)

and after that nothing... No icon in panel, nothing. After the restart od dbus:

NetworkManager: <information>^IActivation (eth1) Stage 2 of 5 (Device Configure) starting...
NetworkManager: <information>^IActivation (eth1/wireless): access point 'xxxxxx' is unencrypted, no key needed.

and everything works OK.

Alexander Sack (asac) wrote :

do you still see that nm-applet vanishes from tray? If its gone can you please see if NetworkManager and NetworkManager process is still running?

Christian Holtje (docwhat) wrote :

I'm sorry. I'm in the middle of upgrading my laptop to Gusty. Do you want me to try this again with Gusty's NetworkManager?


Alex Mauer (hawke) wrote :

I still see it fairly often. Next time it happens I'll check if that process is running.

For me it appears to happen when I roam between different networks (possibly only if I do so when nm-applet is prompting for the gnome-keyring to be opened (which I always deny))...

An alternative explanation is that it happens when many wireless networks are detected while the above happens.

Alex Mauer (hawke) wrote :

>see if NetworkManager and NetworkManager process is still running?

I don't know what you meant by repeating "NetworkManager"; however, the NetworkManagerDispatcher is still running but the NetworkManager process is not.

This happened when I roamed away from an open wireless network that I was connected to.

I'd like to repeat my opinion that the nm-applet should be drawn independent of communication with NetworkManager.

Alexander Sack (asac) wrote :

nm-applet has now its own source package ... reassigning accordingly.

 - Alexander

unggnu (unggnu) wrote :

I have a similar problem. Sometimes after boot nm-applet is running but isn't shown in tray and wlan connection isn't established. After system reboot it works normally fine again.
I have restarted Network-Manager with "sudo /etc/dbus-1/event.d/25NetworkManager restart && sudo /etc/dbus-1/event.d/26NetworkManagerDispatcher restart" which lets nm-applet appear in tray for some seconds but then it was vanished again.
According to syslog there was a problem with wpa_supplicant and according to ps it was still running so I killed it. After another Network-Manager restart nm-applet was shown again in tray and connection was established fine. So at least for me it is no nm-applet problem but a Network-Manager and it seems to be for at least some others too.

Gavin Graham (gavingraham) wrote :

I think this is relevant here: I have also had issues with the network manager applet not loading. I try to restart the network service (/etc/init.d/networking) but to no avail. The only option is to reboot the computer. This is with the ipw3495 chipset btw.
Attached is the relevant section of the daemon.log.

unggnu (unggnu) wrote :

I have made a new bug report against NetworkManager since nm-applet bug report was marked as invalid because this issue is NetworkManager related.

Alex Mauer (hawke) wrote :

System log output from a crash of NetworkManager on my system:

Sep 17 09:33:02 2360lnx NetworkManager: <WARN> nm_signal_handler(): Caught
signal 11. Generating backtrace...
Sep 17 09:33:03 2360lnx NetworkManager: ******************* START **********
Sep 17 09:33:04 2360lnx NetworkManager: Using host libthread_db library "/li
Sep 17 09:33:05 2360lnx NetworkManager: [Thread debugging using libthread_db
Sep 17 09:33:05 2360lnx NetworkManager: [New Thread -1212422480 (LWP 4385)]
Sep 17 09:33:05 2360lnx NetworkManager: [New Thread -1229210736 (LWP 5567)]
Sep 17 09:33:05 2360lnx NetworkManager: [New Thread -1220818032 (LWP 4507)]
Sep 17 09:33:05 2360lnx NetworkManager: [New Thread -1212425328 (LWP 4501)]
Sep 17 09:33:05 2360lnx NetworkManager: 0xffffe410 in __kernel_vsyscall ()
Sep 17 09:33:05 2360lnx NetworkManager: ******************* END ************

unggnu (unggnu) wrote :

It seems that you are experiencing the same bug. Could you please try this workaround if this bug appears:
sudo killall wpa_supplicant
sudo /etc/dbus-1/event.d/25NetworkManager restart

This should work without a computer reboot.

Alex Mauer (hawke) wrote :

How is the crash of NetworkManager a bug in the applet?

The applet not showing up is a bug in the applet, but the cause of it appears to be the crash of NetworkManager.

Or are we seeing two different bugs?

unggnu (unggnu) wrote :

According to the initial bug report http://bugzilla.gnome.org/show_bug.cgi?id=341320
"This is probably the daemon exiting/crashing/breaking. nm-applet is supposed
to vanish from the tray in that case.

If NM is crashing, that is a legit bug, and should be filed with appropriate
back trace."

You could check with ps that nm-applet is normally running and it appears again if you restart NetworkManager at least for some seconds.

Gavin Graham (gavingraham) wrote :

Yes it is the daemon crashing and the bug you refer to has the same output in the daemon log. Trying to start NM will only end up with another crash.
Does this bug need to be re-allocated/categorised?

Anyhow, here is my daemon.log output to show that I am having the same symptoms.

unggnu (unggnu) wrote :

Have you killed wpa_supplicant before restarting NetworkManager like described above?

Maybe we should make a separate bug report for this issue but I am not sure.

Gavin Graham (gavingraham) wrote :

Further to my last post, I am experiencing this on Gutsy Tribe5+Updates. The applet itself seems fine, it is the daemon causing the issue.

Gavin Graham (gavingraham) wrote :

I was meaning to try that as suggested but since then, I have applied todays updates in order to see if Bug #140469 is still an issue and do you think that the NM daemon wants to crash? It's behaving itself at the moment. I'll have to wait for it to happen again I suppose.

Gavin Graham (gavingraham) wrote :

The NetworkManager daemon has died again (I had a good run of about four reboots though!) and as suggested I killed wpa_supplicant prior to restart NetworkManager - It worked! Looks like wpa_supplicant is the culprit huh?

Changed in network-manager:
status: Unknown → New
unggnu (unggnu) wrote :

Since the wpa_supplicant/NetworkManager issue seems to be only Gutsy related I guess we should make a new bug report.

Could you please add your experience to NetworkManager bug report in GnomeTracker http://bugzilla.gnome.org/show_bug.cgi?id=477650 ?

Gavin Graham (gavingraham) wrote :

@unggnu - I have added my comments as suggested to the bug in GnomeTracker and also included another copy of the daemon.log with the portion pertaining to wpa_supplicant

unggnu (unggnu) wrote :

Thanks. There seems to be already another bug report for this issue https://bugs.launchpad.net/network-manager/+bug/139966 . This is no duplicate since some people seems to have another issue.

Changed in network-manager:
status: Unknown → Invalid
Alexander Sack (asac) wrote :

ungnu, gavindi and Alex Maurer: i opened a MASTER bug for your network manager crash in bug 43379. Please subscribe there so you can provide infos and test fixes.

 - Alexander

Alexander Sack (asac) wrote :

sorry ... the right MASTER bug for you is bug 141233

description: updated
Changed in network-manager:
status: New → Confirmed
Alexander Sack (asac) wrote :

lets not track the network-manager crashes in this bug report. network-manager-applet part of this bug is still valid though. I think we can do better than just disappearing from tray when network-manager isn't running (anymore).

Changed in network-manager:
status: Confirmed → Invalid
Steinar Bang (sb-dod) wrote :

This happens for me after an upgrade from Feisty to Gutsy. The nm-applet process dies and the network icon disappears from the tray. If I restart nm-applet it appears in the correct state (ie. wired, connected, with an VPNC connection). After a restart I get the number of nm-applet process that have been started during the session.

Some version info:
 Intel Pentium M,
 linux-image-2.6.22-14-generic 2.6.22-14.46,
 network-manager 0.6.5-0ubuntu16
 network-manager-gnome 0.6.5-0ubuntu10
 network-manager-vpnc 0.6.4svn2422-0ubuntu3

Benjamin Geer (benjamin-geer) wrote :

I'm having a similar problem. When I removed the Tomboy Notes applet from the panel, several other applets disappeared along with it: the network manager applet, the OpenOffice quicklaunch applet, and the Gmail Notifier applet. Using 'ps', I verified that all the applet processes were still running (including nm-applet and NetworkManager). My wireless network connection was still working, too. I rebooted, and the applets didn't reappear, but the computer nevertheless connected to my wireless network.

I then used Synaptic Package Manager to reinstall the network-manager and network-manager-gnome packages, thinking that this might get the applets to reappear, and apparently as a result, the wireless network connection was dropped. I rebooted the machine, but the applets have not reappeared, and the wireless network connection hasn't come back up again. All the applet processes are still running, though; they are just not being displayed. Unfortunately, this means I can't get my network connection working again, since as far as I can tell, the only way to do so is via the Network Manager applet which isn't displayed.

Benjamin Geer (benjamin-geer) wrote :

Now I see what happened. Somehow the "Notification Area" got removed from the panel. I added it back; problem solved. IMHO, it shouldn't be possible to remove it; you can't live without the thing.

Thomas B (tbrownback) wrote :

"If nm-applet isn't running, file a bug against network-manager-applet package; in case NetworkManager isn't running, ..."

What if (as in my case) neither is running?


chaghaboo (marko.niketic) wrote :

I have the same problem with nm-applet becomes invisible without particular reason. I can't even relate it to any other action. There is empty space where nm applet stands in gnome-panel and I can get nm menus on left and right click on that empty space so it doesn't disappear but it simply becomes invisible. Aside it's invisibility it works just normal, I can switch to other networks, get connection status, etc.

Interesting is that in same time nm applet becomes invisible clock applet freezes. Time clock applet is showing freeze, aside of that it works normal as well. It might be problem with gnome-panel?

Can you run 'killall gnome-panel' to force gnome-panel to restart and
see if that has any effect?

chaghaboo (marko.niketic) wrote :

I will try that soon as problem reappear as it comes and goes. Will let you know.

Caue Rego (caue-rego) wrote :

I was having an issue with dnsmasq and sharing my internet connection (which dnsmasq had previously corrected). and this was the sympton: nm-applet vanishing. I came here but before I started to read I decided to do one last attempt to fix it... and it worked, almost magically if I may add :P

on the system manager, I've found dnsmasq running as "dnsmasq -u dnsmasq -r /var/run/dnsmasq/resolv.conf" (I recall it perfectly) and started wondering why that path? after a while I've decided to kill the process and that's when the magic kicked in. next time I tried to set Network Manager to "create a new wireless network" it worked!

and now, on the system manager, I see a whole different new execution line for dnsmasq. it's rather huge now:
 /usr/sbin/dnsmasq --no-hosts --keep-in-foreground --bind-interfaces --no-poll --except-interface=lo --listen-address= --dhcp-range=,,60m --dhcp-option=option:router, --dhcp-lease-max=50 --pid-file=/var/run/nm-dnsmasq-wlan0.pid

later on I try to understand what happened in fact, but I guess this could be somewhat related to this bug, and I hope this info can be of some use. :)

one more thing, when reading the logs when the nm-applet fails it's somehow related to nm-dispatcher. as you can see below, it crashed from a fresh boot exactly at 00:12:43 and so I could link the errors from kern and daemon logs.

Feb 2 00:12:43 caue-laptop kernel: [ 109.608254] nm-applet[6658]: segfault at 0 ip 0000000000410e37 sp 00007fff3150aed0 error 4 in nm-applet[400000+45000]

Feb 2 00:12:43 caue-laptop NetworkManager: <info> (ttyUSB0): device state change: 8 -> 3
Feb 2 00:12:43 caue-laptop NetworkManager: <info> (ttyUSB0): deactivating device (reason: 38).
Feb 2 00:12:43 caue-laptop NetworkManager: <debug> [1233540763.340545] nm_serial_device_close(): Closing device 'ttyUSB0'
Feb 2 00:12:43 caue-laptop NetworkManager: <info> (ttyUSB0): removing resolv.conf from /sbin/resolvconf
Feb 2 00:12:43 caue-laptop NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed
Feb 2 00:12:43 caue-laptop NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed
Feb 2 00:12:43 caue-laptop nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' exited with error status 1.
Feb 2 00:12:44 caue-laptop ntpdate[7032]: sendto( Network is unreachable

Alexander Sack (asac) wrote :

we have fixed nm-applet in intrepid and later so that it always shows up; even if NM isnt running.

Changed in network-manager-applet:
status: Confirmed → Fix Released
MrAnderson (edison-montes) wrote :

Sorry to add new bugs, but nm-applet started to vanish suddenly, and before it worked great with no problems.

Everytime I restart nm-applet with "nm-applet --sm-disable", after a few minutes it vanishes again.

I checked and NetworkManager is running when nm-applet crashes.

root 3251 1 0 08:11 ? 00:00:00 /usr/sbin/NetworkManager --pid-file /var/run/NetworkManager/NetworkManager.pid
root 3271 1 0 08:11 ? 00:00:00 /usr/sbin/nm-system-settings --config /etc/NetworkManager/nm-system-settings.conf
1000 10124 6369 0 09:23 pts/0 00:00:00 grep NetworkManager

Killing wpa_suplicant does not affect the vanishing of nm-applet

BTW I could't restart Network Manager because the commands doesn't work, the result is command not found

sudo /etc/dbus-1/event.d/25NetworkManager restart
sudo /etc/dbus-1/event.d/26NetworkManagerDispatcher restart

I'm using Ubuntu 9.04 with kernel 2.6.28-15-generic and NetworkManager is in version 0.7.1~rc4.1.cf199a964-0ubuntu2

MrAnderson (edison-montes) wrote :

More info... daemon.log shows this info when nm-applet crashes

Aug 28 16:10:12 mranderson-15u NetworkManager: <info> (eth1): device state change: 8 -> 3
Aug 28 16:10:12 mranderson-15u NetworkManager: <info> (eth1): deactivating device (reason: 38).
Aug 28 16:10:12 mranderson-15u NetworkManager: <info> eth1: canceled DHCP transaction, dhcp client pid 7650
Aug 28 16:10:12 mranderson-15u NetworkManager: <WARN> nm_device_wifi_disable_encryption(): error setting key for device eth1: Invalid argument
Aug 28 16:10:12 mranderson-15u NetworkManager: <WARN> check_one_route(): (eth1) error -34 returned from rtnl_route_del(): Sucess
Aug 28 16:10:12 mranderson-15u avahi-daemon[3283]: Withdrawing address record for on eth1.
Aug 28 16:10:12 mranderson-15u avahi-daemon[3283]: Leaving mDNS multicast group on interface eth1.IPv4 with address
Aug 28 16:10:12 mranderson-15u avahi-daemon[3283]: Interface eth1.IPv4 no longer relevant for mDNS.

I don't know if it's the same bug...

saintivan (ivanmk-sk) on 2009-12-23
Changed in network-manager-applet (Ubuntu):
assignee: nobody → saintivan (ivanmk-sk)
And1945 (brandenborg) wrote :

After installing samba network daemon, my network-manager also disappears.

Changed in network-manager:
importance: Unknown → Medium
Saaz Rai (saaz-rai) wrote :

Confirming the issue in Maverick. The issue was there in Lucid as well.

This happens when I use Mobile Broadband connection. The applet vanishes from the system tray but this does not affect the Internet connection.

When I run nm-applet from the terminal I get the following message:
** Message: applet now removed from the notification area
** Message: applet now embedded in the notification area
** (nm-applet:19421): DEBUG: old state indicates that this was not a disconnect 0
** (nm-applet:19421): DEBUG: old state indicates that this was not a disconnect 0

Distro: Ubuntu 10.10 x86
Network Manager Applet: 0.8.1

kay (kay-diam) wrote :

I have the same issue in Maverick amd64.
ps command show that nm-applet is running. I have tried to reboot, but nothing changed.

kay (kay-diam) wrote :

Also when I start applet manually it shows the following message in console:

** Message: applet now removed from the notification area
** (nm-applet:5700): DEBUG: old state indicates that this was not a disconnect 0
** (nm-applet:5700): DEBUG: foo_client_state_changed_cb
** (nm-applet:5700): DEBUG: foo_client_state_changed_cb

moimael (moimael) wrote :

Exact same bug with mobile broadband in maverick 64bits, didn't happend before, maybe an update break something.

launchpadmember (lpuser1138) wrote :

I can also confirm that this bug still seems to be present in v11.04 Natty

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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