GNOME Bugzilla – Bug 591054
Nautilus/gvfs does not handle FTP timeouts well
Last modified: 2015-02-01 11:10:26 UTC
Please describe the problem: I connected to a FTP server via gvfs in Nautilus. After some time the FTP connection is closed automatically, as I observed with wireshark (421 No transfer timeout (300 seconds): closing control connection). After that, everytime I open a folder on the FTP server I get only an "unexpected end of stream" error. To access the FTP server again I have to disconnect and then connect again. Nautilus does not seem to know that the connection closed. A better behaviour IMHO would be to try and reconnect to the FTP server. Bug filed for Ubuntu at https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/410288 Steps to reproduce: 1. Connect to a FTP server with nautilus 2. Wait until the connection timeout 3. Try to access any folder not previously opened Actual results: "unexpected end of stream" error Expected results: A dialog asking me to reconnect or a silent reconnect to the FTP server Does this happen every time? yes Other information:
This should mostly be fixed with the recent refactoring - but it should mostly have worked before, too. I do remember fixing some bug to that, but can't find out where I fixed it and if it should have worked for the reporter. It'd be nice if you could retry with the recent 1.4.0 release and report back, as it works pretty much fine with my local ftp server - and I have set a 10s timeout on purpose just to make sure it keeps working.
When I now acces a folder after the timeout I get the following message: The folder contents could not be displayes. Sorry, could not display all the contents of "folder": Host closed connection When I reload the folder or access a different folder everything works, so the connection to the ftp server is established again. Is this message and behaviour intentional? I'd think that either a silent reconnect without message or a direct reconnect after the display of this message (without having to reload the folder) would be less confusing. I've tried this on a Ubuntu Karmic with gvfs updated to 1.4.0.
Hrm, it works here - maybe your ftp server does something we don't check for. Is it publicly accessible?
I just tried it with different ftp servers, including ftp.gnome.org and I get the message on all of them. Maybe it's a Ubuntu specific bug or something like that.
I can confirm this bug on version 2.30.2. To do so, I am connecting to my FTP server with nautilus, then wait for some time. After a few minutes when I try to reach FTP server (copying or editing file) i get error: Sorry, could not display all the contents of "/ on <domain>": Host closed connection
I have tested this issue on Ubuntu 10.04 and it doesn't occur on Ubuntu. I am facing timeout problem on Arch Linux. Versions of which are mentioned in my previous posts.
I have this problem in gentoo linux. Gnome 2.30
I have reproduced this issue with ftp.gnome.org and packaged GNOME 2.30 on Ubuntu 10.04.
*** Bug 626084 has been marked as a duplicate of this bug. ***
problem still exists in ubuntu 11.10 with Gnome 3.2 (nautilus 3.2.1) and gvfs 1.10.0
I also frequently encounter this issue with Fedora 16, Natuilus 3.2.1 and gvfs 1.10.1. When I copy a file while the connection to the ftp server has timed out (after five minutes of inactivity in my case) I get the error message "There was an error copying the file into <URL>" with "Host closed connection" as the detailed error message. Like comment #2 I think that gvfs should be able to detect if the connection timed out and reconnect silently, so that the action will succeed without giving an error message.
Still exists with 12.04. /:
Some workaround is to force a refresh by accessing the file system once in a while: http://www.flynsarmy.com/2011/08/enable-ftp-keepalives-in-nautilus/
Couls anyone at least set this to confirmed - this bug is bugging my since years. It was reported in 2009, and at least 60 people in Ubuntu found it worth to click on "mee too" on launchpad. I think it affects thousands of silently angry people...
(In reply to comment #14) > Couls anyone at least set this to confirmed - this bug is bugging my since > years. It was reported in 2009, and at least 60 people in Ubuntu found it worth > to click on "mee too" on launchpad. I think it affects thousands of silently > angry people... Well it is unconfirmed by a GVFS developer (that field is mostly ignored anyway). What would be useful is if you could provide the particular server, version and any special configuration that it has with regards to timeouts since Benjamin in comment 1 couldn't reproduce the problem.
Oh. I can provide a test account on my (hosted) server (I will do this temporarily, only read permissions): ftp://f00977df@dd32622.kasserver.com - pw is "PHwAHMkeFnTte4zU". There is only one empty file "test.txt" in it. I don't know the server ftp version and config settings as it's hosted.
Created attachment 282197 [details] [review] ftp: Don't attempt to use unusable connections If a 421 or 426 response is received, mark the connection as unusable so that it is not reused. This prevents races where a 421 error is received and the upper layer does not retry the operation because the connection is still open and considered usable.
Created attachment 282198 [details] [review] ftp: Only free connection if non-NULL Only attempt to free the connection if it is non-NULL, to prevent warnings like the following: ** (process:30854): CRITICAL **: g_vfs_ftp_connection_free: assertion 'conn != NULL' failed The connection can be NULL if g_vfs_ftp_connection_new is cancelled.
(In reply to comment #16) > Oh. I can provide a test account on my (hosted) server (I will do this > temporarily, only read permissions): > ftp://f00977df@dd32622.kasserver.com - pw is "PHwAHMkeFnTte4zU". > There is only one empty file "test.txt" in it. > I don't know the server ftp version and config settings as it's hosted. Thanks for the test account. The above patches fix the problem for me. The second patch is not really associated but I noticed it while I was fixing the timeouts.
Review of attachment 282198 [details] [review]: Looks good, thanks!
I've pushed a bunch of fixes to git master that should fix the problem, so I'm optimistically marking this as fixed. If somebody can still reproduce it, please reopen. I tested a local vsftpd with the config setting idle_session_timeout=10 to timeout after 10s and I waited patiently for ftp.gnome.org to timeout after 10s and they both work fine now. Though they are both vsftpd instances. The ftp server from comment 16 didn't seem to accept the username/password combination anymore so I didn't test that one.
Comment on attachment 282197 [details] [review] ftp: Don't attempt to use unusable connections While this patch does technically the right thing, I didn't like the way it was implemented and consider https://git.gnome.org/browse/gvfs/commit/?id=9bd1bd2c7a96b69ef4de956eb04d3bb58f748c0e a better fix. First, I think I'd prefer g_io_stream_close()ing the control connection to be a better approach to adding a fatal_error boolean, because it encodes the "fatal error" status in the connection. Second, this code special cases the 421 and 426 error codes. And while these are the most common reasons for connections going south, nowhere are these listed as the only ones. I do hope however that the server would close the connection afer sending 421 or 426, so the connection should be marked as unusable after receiving those messages anyway due to the stream being in HUP status. Finally and most importantly, with https://git.gnome.org/browse/gvfs/commit/?id=648c433bfbc88aaa757a0adb86b20ca3c986108b and the above patch we catch the 99% case: The case of the server sending a 421 in the long time we didn't use the connection. And we catch the case before the connection object even makes it to the stage where g_vfs_ftp_connection_receive() gets called. We can drop the connection in the acquiring stsage and not have other code care about this error. The only case this patch doesn't fix is the race where we send a command exactly after 10 minutes while the 421 is already on the way to us but hasn't arrived. In that case (which is roughly as large as the ping time to the server, so I didn't try to reproduce it), I'd expect the 421 to bubble up and the user to potentially see it, but the connection should be marked as unusable because of HUP if the user retries and we'd use a new one then, so there should be no infinite error loop. I hope that makes sense.
Works for me (also tested with vsftpd but the test account had similar behavior when I tested it)... thanks for doing this. I think for that short race you described above, it would most likely be covered because if an error is received (e.g. 421 timeout), ftp_task_sendv checks the connection to see if it usable before retrying. Because the server would most likely have closed the connection when sending the 421 response, the connection will be unusable and ftp_task_sendv will retry.
Sorry, I had turned my testserver off again 'cause I thought you didnn't need it any more. Here is it again, on until you tell me explicitely you don't need it: ftp://f00980ff@dd32622.kasserver.com, PW is "4nrNSwg2adzygDHD".
Thanks. I just did a quick test and it seems to work there, too. What I did: > gvfs-mount ftp://f00980ff@dd32622.kasserver.com ...wait 10= minutes ... > gvfs-ls ftp://f00980ff@dd32622.kasserver.com previous result: Error: Host closed connection result with git master: test.txt So it seems the bug really is fixed and for all I care you can turn off your server again.
*** Bug 635245 has been marked as a duplicate of this bug. ***
*** Bug 707103 has been marked as a duplicate of this bug. ***