On 02/04/2011 06:09 PM, Gerry Reno wrote:
On 02/04/2011 06:01 PM, Gerry Reno wrote:
On 02/04/2011 04:43 PM, Mike Gabriel wrote:
Hi Gerry,
On Fr 04 Feb 2011 22:14:28 CET Gerry Reno wrote:
Has anyone found out how to prevent this "remote proxy closed the connection" error from happening when a session becomes detached and a user tries to resume the session?
We are seeing this problem quite often and every once in a while you can get it to resume but mostly this session is unrecoverable and must be manually terminated - which is creating much sysadmin work.
Test the following:
Whenever this error occurs, restart your X2go server's SSH daemon. My guess is that you can resume the session once SSH is restarted.
I have read about weird port forwarding habits of the SSH daemon... I also meet these problems with PyHoca-GUI.
Greets, Mike
Ok, the plot thickens.
I took a look at netstat both prior-to and after we get this error:
# normal state # we can successfully resume a session
# netstat -a | grep 300 tcp 0 0 localhost:30008 *:* LISTEN tcp 0 0 localhost:30009 *:* LISTEN tcp6 0 0 ip6-localhost:30008 [::]:* LISTEN tcp6 0 0 ip6-localhost:30009 [::]:* LISTEN# # after I forced a session to detach
# netstat -a | grep 300 tcp 0 0 localhost:30008 *:* LISTEN tcp 0 0 localhost:30009 *:* LISTEN tcp 0 0 localhost:33552 localhost:30037 TIME_WAIT tcp6 0 0 ip6-localhost:30008 [::]:* LISTEN tcp6 0 0 ip6-localhost:30009 [::]:* LISTEN# # if we just wait for a while then reattempt to resume the session it succeeds
# netstat -a | grep 300 tcp 0 0 localhost:30008 *:* LISTEN tcp 0 0 localhost:30009 *:* LISTEN tcp6 0 0 ip6-localhost:30008 [::]:* LISTEN tcp6 0 0 ip6-localhost:30009 [::]:* LISTENSo whatever is causing this TIME_WAIT is what appears to have a role in the error.
Regards, Gerry
What's interesting is that it presents the menu and the process is shown as "running" so then your "suspend" it and "resume" it and you still get the "remote proxy closed the connection" error and NX proxy shows "aborting" but it does resume the session. Very confusing to users but at least they get their session back.
Regards, Gerry
The TIME_WAIT occurs on the server because apparently there is no keep_alive which would make the client responsible for closing the connection. I didn't see any TCPKeepAlive=yes in the ssh options which may be accounting for TIME_WAIT showing up on the server. <snip> Hmm . . . not sure but it rings a bell that 300 seconds is hard coded in
On Fri, 2011-02-04 at 20:31 -0500, Gerry Reno wrote: the client - John