This is actually a feature, not a bug. Before this, the system would log out at the loss of unsaved work and be blind to any damage.
Nowadays, applications that perform lengthy tasks worth awaiting, register themselves via DBus with the shell; these can be video encoding, uploading and syncing Ubuntu One or DropBox tasks and so on.
Sometimes applications may crash and therefore fail to deregister their pending tasks, and they may or may not be firefox.
You can investigate your shutdown inhibitor with any DBus viewer like d-feet:
On the session bus, the org.gnome.SessionManager interface will expose the method GetInhibitors(), which returns for example ['/org/gnome/SessionManager/Inhibitor2']. The object at this path will allow you to query various things, like GetAppId() (e.g. Handbrake), GetReason() (e.g. Encoding), GetToplevelXid() (e.g. 79691816L). Especially the latest may be of use: You could issue xwininfo -id 79691816 and thus verify if the window still exists and if it does, what its real title is.
Firefox has been suffering from a bad memory leak for a long time. And it has only gotten worse the last few releases (4, 5 & 6).
I often get this "Not responding" message and by trial & error have learned that it is coming from Firefox. To see if Firefox is causing this on your computer, consider trying the follow procedure:
when you get the Not Responding dialog, open System Monitor. Look for the firefox-bin executable in the Processes list and if you find it see if the Waiting Channel header says "futex_wait_queue_me":
If you see this entry, open a Terminal and type "killall firefox-bin". This commmand will terminate the process.
Now repeat whatever you did that created the Not Responding dialog (e.g., trying to restart or shutdown the computer) and see if everything is copacetic. If everything's smooth and you don't get another Not Responding dialog, you can deduce that it was the Firefox memory leak causing it.
This is actually a feature, not a bug. Before this, the system would log out at the loss of unsaved work and be blind to any damage.
Nowadays, applications that perform lengthy tasks worth awaiting, register themselves via DBus with the shell; these can be video encoding, uploading and syncing Ubuntu One or DropBox tasks and so on.
Sometimes applications may crash and therefore fail to deregister their pending tasks, and they may or may not be firefox.
You can investigate your shutdown inhibitor with any DBus viewer like d-feet:
On the session bus, the
org.gnome.SessionManagerinterface will expose the methodGetInhibitors(), which returns for example['/org/gnome/SessionManager/Inhibitor2']. The object at this path will allow you to query various things, likeGetAppId()(e.g. Handbrake),GetReason()(e.g. Encoding),GetToplevelXid()(e.g. 79691816L). Especially the latest may be of use: You could issuexwininfo -id 79691816and thus verify if the window still exists and if it does, what its real title is.Firefox has been suffering from a bad memory leak for a long time. And it has only gotten worse the last few releases (4, 5 & 6).
I often get this "Not responding" message and by trial & error have learned that it is coming from Firefox. To see if Firefox is causing this on your computer, consider trying the follow procedure:
when you get the Not Responding dialog, open System Monitor. Look for the firefox-bin executable in the Processes list and if you find it see if the Waiting Channel header says "futex_wait_queue_me":
If you see this entry, open a Terminal and type "killall firefox-bin". This commmand will terminate the process.
Now repeat whatever you did that created the Not Responding dialog (e.g., trying to restart or shutdown the computer) and see if everything is copacetic. If everything's smooth and you don't get another Not Responding dialog, you can deduce that it was the Firefox memory leak causing it.
Try running the grub update:
sudo update-grub
I had the same problem described above and this fixed it for me.