nautilus uses 100% cpu after closing a ssh session

Bug #27109 reported by mon
64
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Nautilus
Fix Released
High
gvfs (Ubuntu)
Fix Released
Medium
Ubuntu Desktop Bugs
nautilus (Mandriva)
Invalid
Undecided
Unassigned

Bug Description

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.

http://bugzilla.gnome.org/show_bug.cgi?id=325979: http://bugzilla.gnome.org/show_bug.cgi?id=325979

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug. I've forwarded it upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=325979

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :

FYI this still happens in dapper up to date

Revision history for this message
saads (shakhshir) wrote :

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'.

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :

confirmed by saad

Changed in nautilus:
status: Unconfirmed → Confirmed
Changed in nautilus:
assignee: seb128 → desktop-bugs
Revision history for this message
Dennis Heinson (dheinson) wrote :

i had a similar error when transfering ftp. fix was commited by irc #nautilus user alex to cvs yesterday or the day before.

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :

The upstream bugtracker still shows this bug opened, so maybe the ftp bug is a different one?

Revision history for this message
Martin Jensen (martin-mdc) wrote :

I might add that similar behaviour comes up when trying to connect to a remote ssh server fails.

1) add a remote ssh server via "places"
2) doubleclick the shortcut to this server via the desktop.
3) Above does not react now and then (another bug, I know)
4) Nautilus starts using 100% cpu.

Regards

/Martin

Revision history for this message
Sebastien Bacher (seb128) wrote :

Martin, could you get a backtrace (https://wiki.ubuntu.com/Backtrace) when nautilus use 100% cpu?

Revision history for this message
UbuntuLover (woshug3lvqhfmjd) wrote :

I also experience this bug regularly when copying (large) files from a NFS-mounted directory.
Nautilus consumes > 80% of CPU-usage after the copy-process is finished.

I've been living with this bug for quite a while now; and I thought it would be fixed pretty soon since the bug is listed here and Nautilus is a major component of the GNOME-Desktop.
Hope it will be fixed soon and updated via new packages.

Revision history for this message
Jan Frybort (jan.frybort) wrote :

I can also confirm this problem in Feisty on amd64. Hope it gets fixed sometime.

Revision history for this message
Joey Stanford (joey) wrote :

I'll add another "me too" to the list.

Revision history for this message
Byenary (goldstrike) wrote :

Me to, when I shut-down the computer while ssh-ing with it nautilus gets sick but after a while (about 10 min) nautilus is being healed and does not consume more cpu than normal...

Revision history for this message
doclist (dclist) wrote :

I am still experiencing this in Feisty.

What seems to regularly reproduce the problem for me is to delete a file on the ssh server (from Nautilus). Shortly after Nautilus goes to 100% CPU. I would guess that the bug stems from Nautilus assuming that the deleted files are still there and doing an operation based on that incorrect assumption, resulting in a spin-lock.

Changed in nautilus:
status: Confirmed → Triaged
Revision history for this message
Kent deVillafranca (kdevilla) wrote :

I just experienced this in Gutsy, so it hasn't been fixed yet...

Revision history for this message
knarf (launchpad-ubuntu-f) wrote :

On my Gutsyfied (from Feisty to Gutsy beta) Thinkpad T23 Nautilus goes to 100% CPU when the Gnome session is terminated. Best way to see this is to switch user from A to B, terminate user B's session and go back to A. The CPU is pegged with user B's dying Nautilus.

Possibly related: I quite often have to shoot down bonobo-activation-server to get Nautilus to start after having logged in and out once without a reboot.

Terminating Nautilus (using nautilus -q) also leads to the dying nautilus hogging the CPU, all the while spewing dire '0x8177880 2007/09/30 23:26:54.2265 (USER): debug log dumped due to signal 11' warnings into nautilus-debug-log.txt at a rate of app. 7000 messages per second. After killing the morbid nautilus the CPU gets pegged by tracker which insists on indexing this logfile (easily remedied by deleting the offending log file but still...)

Revision history for this message
Plareplane (plareplane) wrote :

nth-ing here on Gutsy beta.

My reproduction:
1. Start nautilus on machine A
2. On machine A, have nautilus connect server (ssh) to machine B
3. Copy files from machine B to machine A
4. Turn off machine B
5. Machine A's nautilus is now stuck at 100%

What commands can I run to give more useful info?

Revision history for this message
ScrewITfix (screwitfix) wrote :

Hi
I got the same trouble with Gutsy, but I figured out that, when I "Close" or Umount the SSH connections, Nautilus comes down to normal.
It looks like Nautilus tries to keep the SSH connections alive spending 100% of CPU power. Sad thing is, that I now always need to Reconfigure the connection to the SSH server.

cheers Claus

Revision history for this message
Ian Ohr (munk3h) wrote :

I get the same as screwITfix on gutsy. It takes about 10 seconds for nautilus to come down from 100% CPU usage when you unmount the connection

Revision history for this message
Carl Englund (englundc) wrote :

Ok, so this bug is about two years old now.. I guess it's related to my problem: In Edubuntu the clients connect via SSH. After people log out a Nautilus process is sometimes left running @ 100% CPU forcing me to kill it. It happens almost every day and slows the server (and clients) to a crawl.

What can I do to help get this fixed?

Revision history for this message
fazulas (fizolas) wrote :

I can also confirm this bug, using Nautilus 2.20.

Revision history for this message
ASULutzy (ryan-lutz) wrote :

I am also confirming this bug, connecting to my desktop from my laptop via Places -> Connect to Server in the Gnome menu and selecting ssh and providing the server ip (in this case 192.168.0.104 note using private key authentication). Nautilus' CPU utilization will spike to 100%.

If I right click on the folder created to the desktop that says "sftp on 192.168.0.104" and choose unmount volume, the CPU usage returns to normal.

Here's some info that may be helpful:
ryan@lappy:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.10
Release: 8.10
Codename: intrepid

ryan@lappy:~$ apt-cache policy nautilus
nautilus:
  Installed: 1:2.24.1-0ubuntu1
  Candidate: 1:2.24.1-0ubuntu1
  Version table:
 *** 1:2.24.1-0ubuntu1 0
        500 http://us.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status

Revision history for this message
ASULutzy (ryan-lutz) wrote :

I am having difficulty reproducing the bug, I never actually noticed when it spiked, but I was checking top and noticed that nautilus was using 100% CPU. It remained like this for several minutes until I took the steps mentioned in the previous post (unmounted the sftp folder)

Doing that immediately reduced the CPU usage to a much lower %.

Revision history for this message
Günter (guenter-grodotzki) wrote :

I have similar problem but with samba-mounts. Unfortunately I can not reproduce, but I had two samba mounts via nautilus, one of them caused nautilus to use 100% CPU, as unmounting reduced the cpu-usage immediately.

Revision history for this message
TMIT World (0-admin-tmitworld-co-uk) wrote :

We use SFTP for managing multiple websites. This is a total pain and is making Ubuntu unusable in our core business. The bug seems to have been in Ubuntu since January 2006 - surely there must be a fix for this critical bug by now??? Nautilus is still consuming 100% of CPU even after a cold re-boot.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the bug is not happening to everybody and there is no clear way to trigger it

Revision history for this message
TMIT World (0-admin-tmitworld-co-uk) wrote :

Solved it we hope! Dump Nautilus; use Konqueror.

Revision history for this message
Miguel Branco (mpbbranco) wrote :

I think that this is not right way to handle a bug that has been reported since three years and through even more distros releases.

I've just landed here for the first time since I'm using nautilus for sftp and was worried by this strange cpu activity even - and especially - after the download would end, fearing that my transfers could not have been cleanly closed. True that ie used in the past (more than a year ago) sftp and didn't recall this behaviour.

I can reproduce at any tine: just open a remote sftp window and transfer (I've dragged the directory from my local directory window and dropped). Can see any other special setup that could influence, except that I 'm running a SSVNC session thus having two ssh sessions. Also I'm using key authentication, in case this matters.

Revision history for this message
Miguel Branco (mpbbranco) wrote :

Just another hint that just happened: I've tried to unmount the sftp folder and the desktop was frozen (only, other app widows would work normally) then all icons simply disappeared. Killing the sftp process made reappear the desktop icons.

So maybe it a problem rather linked to the display of the sftp volume on the desktop. In the past I had complain to no avail to the rather lousy implementation of this desktop icon, which bring you back to root directory after first login, so maybe it's more a dbus issue or whatever.

Revision history for this message
Sense Egbert Hofstede (sense) wrote :

Marking this task for Mandriva as Invalid since it's not necessary. Please only open a new task for another project when you're actually reporting a bug there or when it's the proper upstream of the package.

Changed in nautilus (Mandriva):
status: New → Invalid
Revision history for this message
Sense Egbert Hofstede (sense) wrote :

Moving this to GVFS since comments in the upstream GNOME bug report indicate that this issue is/was GVFS related; gedit is also affected.
Can anyone actually still confirm this bug after all those years?

affects: nautilus (Ubuntu) → gvfs (Ubuntu)
Revision history for this message
Greg Hellings (greg-hellings) wrote :

I can confirm this bug, even after all this time. It drives me absolutely bonkers and causes all sorts of problems for me. I moved the SSH off of Nautilus and it got a bit better, but I observe the exact same behavior when I'm connecting to FTP servers with Nautilus' ftp:// transport. It makes even navigating local files nearly impossible.

Revision history for this message
Robert "DocSalvager" Watson (robertcwatson) wrote :

I can confirm this bug. Running Ubuntu 8.04.4 (Hardy) on Toshiba Satellite A15-S129 and HP Pavilion a400n. Regularly use File Manager (Nautilus) via SSH between the two. After some period of inactivity, return to find both machines at around 60% CPU.

Changed in nautilus:
importance: Unknown → High
Revision history for this message
Melroy van den Berg (melroyvandenberg) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Upstream says the issue is fixed in the current version

Changed in gvfs (Ubuntu):
status: Triaged → Fix Released
Changed in nautilus:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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