x2go connections no longer possible after upgrade to Ubuntu 20.04

Premable

Before I go off on one about this, I have to say that when it works x2go is actually really quite good. It's fast and supports multiple monitors well.

RVM

I have had a similar problem and done a bit of digging to try to work out what the problem is.

In my case what would happen was that I'd start up the client and try to connect to the server. After a minute I'd briefly see the PANIC message in the client and then nothing. No way to see the error message unless you start x2go client with --debug from the command line.

Really, really not helpful.

In my personal situation it was rvm that highlighted the issues. Others have seen the same:

• https://johnnn.tech/q/after-update-to-ubuntu-20-04-problmes-with-x2go-login/
• https://lists.x2go.org/pipermail/x2go-user/2020-April/005962.html

Root Cause

The clue to it all can be found in this message from a number of years ago: https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1091#10

The key part of it is the statement:

Newer X2Go Client versions started calling bash as a login shell, which implies executing scripts like ~/.profile, ~/.bash_profile, ~/.bashrc and the like. If you have anything in there that outputs to stderr, X2Go Client will abort the connection.

I have some major issues with this:

1. Firstly, there's no explanation why a login shell is used.
2. The same applies to why .profile, .bash_profile and .bashrc are called. This can cause PATH problems as any terminals opened in an x2go session will effectively have .profile (et al) called multiple times.
3. It makes no sense for the client to fail if something outputs to stderr.

This seems to be borne out of laziness, some obscure reasoning and a failure to implement proper error handling on the part of x2go developers.

Correct Solution

This is a problem created by the x2go developers and they should be the ones to fix it. So they need to look at the following:

• Drop the calls to user login scripts
• Fix the error handling mechanisms and provide meaningful error messages
• Don't fail the entire process unnecessarily - namely ignore stderr output

In the Real World

I don't expect any of the above proposals to actually happen so in reality you need to go to some lengths to workaround these dumb issues. So:

• Make sure your login scripts don't have any errors in them
• Make sure your login scripts (.bash_profile, .profile, .bashrc) don't output to stderr.

One way to do this is to append 2>/dev/null all over the place in these scripts.

So for those of you using rvm change:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*

to:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" 2>/dev/null  # Load RVM into a shell session *as a function*

I hope this helps someone. This obscure issue has wasted far too much of my time and nobody else should suffer as a result.