On 02/02/2011 09:48 PM, Gerry Reno wrote:
On 02/02/2011 09:35 PM, Gerry Reno wrote:
I'm seeing the following errors trying to connect to a new machine running server version 3.0.99 using the browser client:
Feb 3 02:20:33 newmachine su[16393]: pam_unix(su:session): session opened for user ubuntu by (uid=0) Feb 3 02:20:33 newmachine sudo: ubuntu : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/touch /root/firstlogin_done Feb 3 02:20:33 newmachine sshd[16319]: Accepted publickey for ubuntu from XXX.XXX.XXX.XXX port 51610 ssh2 Feb 3 02:20:33 newmachine sshd[16319]: pam_unix(sshd:session): session opened for user ubuntu by (uid=0) Feb 3 02:20:33 newmachine sshd[16320]: Accepted publickey for ubuntu from XXX.XXX.XXX.XXX port 51609 ssh2 Feb 3 02:20:33 newmachine sshd[16320]: pam_unix(sshd:session): session opened for user ubuntu by (uid=0) Feb 3 02:20:33 newmachine sshd[16441]: error: bind: Address already in use Feb 3 02:20:33 newmachine sshd[16441]: error: channel_setup_fwd_listener: cannot listen to port: 30008 Feb 3 02:20:33 newmachine sshd[16234]: pam_unix(sshd:session): session closed for user ubuntu Feb 3 02:20:33 newmachine su[16393]: pam_unix(su:session): session closed for user ubuntu Feb 3 02:20:33 newmachine sshd[16524]: error: connect_to localhost port 30007: failed. Feb 3 02:20:33 newmachine sshd[16232]: pam_unix(sshd:session): session closed for user ubuntu Feb 3 02:20:33 newmachine sshd[29561]: channel 2: open failed: connect failed: Connection refused Feb 3 02:20:33 newmachine sudo: ubuntu : TTY=unknown ; PWD=/home/ubuntu ; USER=root ; COMMAND=/usr/bin/touch /root/firstlogin_done Feb 3 02:20:33 newmachine sudo: ubuntu : TTY=unknown ; PWD=/home/ubuntu ; USER=root ; COMMAND=/usr/bin/touch /root/firstlogin_done Feb 3 02:20:33 newmachine sshd[16233]: pam_unix(sshd:session): session closed for user ubuntu
The client reports: Resuming Aborting Error message appears:
The remote proxy closed the connection while negotiating the session. This may be due to the wrong authentication credentials passed to the server. FinishedI ran a check for sessions and there is only one existing session.
I've triple-checked the credentials and logged in on command line using them.
Here's what we have for x2go processes:
ubuntu 3219 1 0 Feb02 ? 00:00:50 /usr/lib/x2go/x2goagent -dpi 96 -D -auth /home/ubuntu/.Xauthority -geometry 1005x552+113+232 -name X2GO-ubuntu-51-1296672519_stDGNOME_dp24 :51 ubuntu 3690 1 0 Feb02 ? 00:00:00 /bin/bash /usr/bin/x2goruncommand 51 3219 ubuntu-51-1296672519_stDGNOME_dp24 30008 gnome-session nosnd D root 15119 1 0 Feb02 ? 00:00:04 /usr/bin/perl /usr/sbin/x2gocleansessions
So there is an existing session. I got detached from it when the browser crashed.
It seems as though the client should either automatically attach to the session or present the user with the list of sessions to take some action.
Regards, Gerry
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. <snip> Interesting - we have seen a lot of this, too, and had just assumed it was an error in the substantial customizations we had made to the
On Fri, 2011-02-04 at 16:14 -0500, Gerry Reno wrote: scripts. We have noticed that, when users are cutoff, e.g., the Internet connection drops, they are presented with a list of running sessions when they reconnect but attaching to a running session almost never works.
We have a related nightmare of a problem with a user running Windows XP on a very old computer who can almost never successfully connect. Sometimes the session starts and then never completes. We can see the "running" session in the database but we know the session has not started because the memory in the vserver is only 20MB - i.e., no KDE. The same user is constantly getting incorrect password errors to the point that OSSEC locks them out of any communication with the X2Go Server. This is no matter how carefully we enter the password.
We have been assuming this last problem has something to do with timing, i.e., the computer takes so long to respond that something times out and is considered a wrong password. We have great hopes that the new client using libssh will respond more quickly and solve this problem as we suspect it will be much faster working directly with the Windows network stack than Cygwin shimming its own between the application and the Windows stack as well as adding its own overhead to a very slow computer. I hope we will find out this weekend when we try putting this user on our experimental vcxsrv/libssh version - John