On Mon, 2011-08-01 at 14:38 -0400, John A. Sullivan III wrote: > On Mon, 2011-08-01 at 13:30 -0400, John A. Sullivan III wrote: > > On Fri, 2011-07-29 at 10:21 +0200, Mike Gabriel wrote: > > > Hi Daniel, > > > > > > On Fr 29 Jul 2011 07:24:40 CEST Daniel Lindgren wrote: > > > > > > > [...] > > > > > > > > I've been trying to think of some way to make x2go automatically only > > > > use free ports, but since there are possibly several clients and > > > > servers involved in multiple incoming and outgoing sessions, the only > > > > safe way I've come up with would be to register used ports (or reserve > > > > port ranges) on a shared resource somewhere, which would make all x2go > > > > clients and servers dependent on that one resource. > > > > > > What you have been describing above is the old, well known > > > NXServer/NXClient problem. > > > > > > To my experience it does not exist with X2go (at least not with > > > pyhoca-gui ;-) ). > > > > > > The connecting stuff is a bit tricky... > > > > > > - x2goclient connects via SSH and launches either x2gostartagent or > > > x2goresume-session > > > - x2gostartagent will try to detect a free server-side port >30000. > > > This port is put into the session database table. (Make sure you do > > > not have other server-side stuff running that claims ports between > > > 30000 and 30000++. > > > - x2goresume-session will pick the formerly detected port from the > > > session > > > database table (i.e. SQLite or postgres) and presume it is still > > > unused > > > (as it should be, unless unused by X2go -> x2gostartagent avoids > > > claiming > > > ports that are in the database marked with S (suspended) or R > > > (running) > > > state > > > - say we detect a free server-side port: 30015: x2gostartagent will > > > launch the > > > XNest-like x2goagent XServer, listening for incoming connections on > > > port > > > localhost:300015. > > > > > > - x2goclient now tries to set up a forwarding tunnel from > > > client to server (-L 30000:localhost:30015) > > > - if the local port 30000 (the first one in the above expression) is > > > already > > > in use, it simply selects another port. Each selected port is > > > probed before > > > usage. That is done by x2goclient. > > > - say we end up with -L 30028:localhost:30015 > > > > > > The problem you observe: ”the remote proxy closed the connection while > > > negotiating …” to my point of view stems from uncleanly closed SSH > > > connections. Try to restart the SSH daemon when this error occurs and > > > you should be able to connect again. This error can also be caused by > > > the sound/sshfs tunnels. Here the same cause applies: unclean shutdown > > > of SSH connections. > > > > > > Reasons may be: > > > > > > o unclean x2goclient/pyhoca-gui code > > > o line failures (so the clients do not get the chance to cancel the > > > port > > > forwarding requests...) > > > > > > You may do the following to debug: > > > > > > o try if the problem occurs in the same way when you use > > > pyhoca-gui/-cli > > > o pyhoca-gui (i.e. python-x2go) tries to restore the mal-closure of SSH > > > port forwardings... You may try to resume a session twice, the second > > > time you should get a session window > > > > > > The addressed issue was a big problem for Python X2go before version > > > 0.1.0.0. It took me quite some sleepness nights to get rid of it by > > > 90%+. > > <snip> > > I continue to have a devil of a time with this. It seems like > > > > - x2goclient now tries to set up a forwarding tunnel from > > client to server (-L 30000:localhost:30015) > > - if the local port 30000 (the first one in the above expression) is > > already > > in use, it simply selects another port. Each selected port is > > probed before > > usage. That is done by x2goclient. > > > > isn't working. In the past, using older clients, we would generate > > error messages about a problem connecting on port 30001 but the sessions > > would all still work. > > > > We are no longer seeing those errors. Instead, the sessions are rudely > > dropped. I've restarted all the X2Go servers and clients after deleting > > all the old session directories on both. Still no success. Here are > > the details. > > > > In our environment, we have a single PostgreSQL database for all the > > X2Go servers. There is one X2Go server for each user (x2go client). > > I connect to the first server and I start a valid session. I am using > > ports 30001 - 30003 on the server side and 30004 on the client side: > > tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN > > > > Server User Status Last Connection Run > > Time Display Client GP SP FP Context Load > > RSS VSZ > > jasiii jasiii S 01.08.11 12:45:12 0d 0h > > 2m 51 74.75.231.235 30001 30002 30003 40016 0.04 > > 434.2Mb 8.4Gb > > > > I start a second x2goclient to connect to the second server. The client > > is listening on port 30005: > > tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN > > tcp 0 0 0.0.0.0:30005 0.0.0.0:* LISTEN > > > > The server side is using the same ports as the other x2go server: > > Server User Status Last Connection Run > > Time Display Client GP SP FP Context Load > > RSS VSZ > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------- > > cuser-a6 cuser-a6 R 01.08.11 12:45:06 0d 0h > > 1m 53 74.75.231.235 30001 30002 30003 40046 0.01 > > 315.3Mb 5.9Gb > > jasiii jasiii S 01.08.11 12:45:12 0d 0h > > 2m 51 74.75.231.235 30001 30002 30003 40016 0.04 > > 434.2Mb 8.4Gb > > > > This is where the original session dies. If I understand the logic, > > shouldn't there be a mapping from 30004 to localhost:30001 for the first > > session and another from 30005 to localhost:30001 for the second > > session? Why is the first session dropped as if there was no network > > connectivity? > > > > This is what the server side session.log says: > > Error: Failure reading from the peer proxy. > > Error: Connection with remote peer broken. > > Error: Please check the state of your network and retry. > > Session: Display failure detected at 'Mon Aug 1 12:45:07 2011'. > > > > Sometimes, it can get really ugly: > > Error: Failure reading from the peer proxy. > > Error: Connection with remote peer broken. > > Error: Please check the state of your network and retry. > > nxagentReconnectFailedFonts: WARNING! Font server tunneling not > > retrieved. > > *** glibc detected *** /usr/lib/x2go/x2goagent: corrupted double-linked > > list: 0x0000000001131d10 *** > > ======= Backtrace: ========= > > /lib/libc.so.6(+0x71ad6)[0x7f05278fbad6] > > /lib/libc.so.6(+0x71f4d)[0x7f05278fbf4d] > > /lib/libc.so.6(+0x73418)[0x7f05278fd418] > > /lib/libc.so.6(cfree+0x6c)[0x7f052790084c] > > /usr/lib/x2go/libX11.so.6(XFreeFontPath+0x1d)[0x7f05295ff8dd] > > /usr/lib/x2go/x2goagent[0x485af8] > > /usr/lib/x2go/x2goagent[0x4ab421] > > /usr/lib/x2go/x2goagent[0x4ab840] > > /usr/lib/x2go/x2goagent[0x4ab95b] > > /usr/lib/x2go/x2goagent[0x48cb75] > > /usr/lib/x2go/x2goagent[0x450bbb] > > /usr/lib/x2go/x2goagent[0x45c65e] > > /usr/lib/x2go/x2goagent[0x429595] > > /usr/lib/x2go/x2goagent[0x455863] > > /lib/libc.so.6(__libc_start_main+0xfd)[0x7f05278a8c4d] > > /usr/lib/x2go/x2goagent[0x40aa69] > > > > The client side says this: > > Loop: WARNING! Connected to remote version 3.4.0 with local version > > 3.5.0. > > Loop: WARNING! Unrecognized session type 'unix-kde-depth_24'. Assuming > > agent session. > > Proxy: PANIC! Failure reading from the peer proxy on FD#5. > > Loop: PANIC! No shutdown of proxy link performed by remote proxy. > > > > So what changed? Is this an issue with libssh? Thanks - John > <snip> > I'm not sure where it is coming from but sometimes, not all the time, we > receive a message such as: > > channel_open_session failed - Received SSH_MSG_DISCONNECT: Received ieof > for nonexistent channel 0 > > Lots of Internet research didn't produce a lot of helpful information on > the error. > > On the server side ssh logs I see: > Aug 1 12:45:07 jasiii sshd[22977]: error: connect_to localhost port > 30001: failed. > Aug 1 12:45:07 jasiii sshd[22977]: channel_by_id: 0: bad id: channel > free > > I do not see anything of interest in the client ssh logs. > > Out of curiosity, I tried reproducing this manually. Both systems where > I can reliably reproduce this problem have a local smtp daemon. I did a > "ssh -p <some hidden port> -L 40015:localhost:25 user1@machine1" and a > "ssh -p <some hidden port> -L 40016:localhost:25 user2@machine2". I was > able to telnet to each on port 40015 and 40016 without an issue or one > disconnecting the other. Could there be a problem in the way libssh is > handling multiple channels? - John > > _<snip> Correction - we are getting error messages about the connection on 30001:
Aug 1 12:32:21 jasiii sshd[11630]: error: connect_to localhost port 30001: failed. Aug 1 12:32:21 jasiii sshd[11630]: channel_by_id: 0: bad id: channel free _______________________________________________ X2go-Dev mailing list X2go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev