GNOME Bugzilla – Bug 325979
nautilus uses 100% cpu after closing a ssh session
Last modified: 2013-11-14 15:01:36 UTC
This bug has been opened here: http://bugzilla.ubuntu.com/show_bug.cgi?id=21021 "When I open a ssh connection to my other computer from my laptop, everything is fine & nautilus works as usual, but, if I close the window with the ssh connection to my other computer & then shut down the computer, nautilus starts consuming 100% cpu time. I assume this is because it's trying to check if the ssh connection is still alive, or the server available, but the fact is that if I launch top, nautilus is using 100% cpu time. So, to reproduce, log in gnome. create a ssh connection to another computer (with connect to another computer link from he places menu). do something in the remote computer (for instance copy a file). Close the window with the ssh connection & shutdown the remote computer. If you wait a bit nautlius should start consuming 100% cpu. I'm using breezy up to date."
I've had the same issue for some time now and I've got a better way to reproduce. Open an SSH connection to somewhere, then kill the process that opened the socket. The socket goes to TIME_WAIT and momentarily nautilus will get extremely confused and start eating your CPU like it's candy. Really tasty candy. My ps output for the offending process looked like this: <pid> pts/0 Ss+ 0:00 -oForwardX11 no -oForwardAgent no -oClearAllForwardings yes -oProtocol 2 -oNoHostAuthenticationForLocalhost yes -p 22 -l <user> -s <server> Interestingly, I don't see an actual command in there anywhere. Just a bunch of commandline arguments. I've got this error on Dapper Drake and two Gentoo machines of different architectures. I'm running 2.14 on all of them.
Bug URL is now: https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/27109 New comment: "Yes I can confirm this in both Dapper and Edgy. Whenever the network connection between the two hosts is terminated, nautilus on the client (the one downloading) hits 100% CPU and remains there. It's quite a serious bug because the only way to bring back down the cpu is to do a 'killall nautilus'."
FYI This still happens in gnome 2.16 Could someone confirm it?
I had a big problem with Nautilus in Dapper where it would crash fairly randomly when using SSH connections. It would do this several times a day. I upgraded to Edgy a couple of weeks ago, and although Nautilus no longer bombs out and is forced to reload, it now consumes 100% CPU. Again, I am still using SSH connections and find the only way to fix this is to use the system monitor to end the Nautilus process. I would help in producing some debug output with symbols, but I am unsure how to achieve this as Nautilus no longer initiates the Bug Report tool.
Potentially related backtrace of nautilus when it was taking 100% CPU after a failed attempt to login to an SSH host. (gdb) bt
+ Trace 117728
This could also be the same bug: https://bugzilla.novell.com/show_bug.cgi?id=222490
I can confirm this bug still exists in the version of Gnome that is used in Ubuntu 7.10 - Gutsy. What information is needed to get this bug to confirmed status.
I should have quoted the Gnome version in the last comment Gnome 2.20.1 I suggest this bug be adjusted to reflect the versions of Gnome it still exists in.
I just wanted to say that I still see this bug in GNOME 2.24 (from Ubuntu Intrepid), and I even have it with gedit from time to time (gedit uses 100% cpu if a file is opened through gvfs but the server doesn't respond anymore), but I don't know whether it's related.
-> gvfs Users on the Launchpad bug seem to report this still applies to recent versions as well.
I can not reproduce this issue (I was trying to trigger it to help track down the cause of another upstream bug https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/377322). Can anyone confirm is this is still and issue with a current version?
I haven't seen this issue in a couple years.
I haven't had this bug lately, not sure when it stopped so I'm not a 100% sure if it's fixed.
This bug appears to have been fixed sometime. Closing as fixed.