On 10/07/2017 01:07 PM, Frank Steiner wrote:
we just tried to x2go for the first time (client 4.0.5.2 server 4.0.1 on SLED 12). It works fine for users with bash as login shell on the server side, but fails for those with tcsh.
4.0.5.2 is quite old by now. This said, the change that explicitly calls bash on session startup came in with 4.0.5.0 (which used "sh" previously) and was updated to use bash as login shell explicitly was part of 4.0.5.1, so 4.0.5.2 should be able to handle that situation.
According to http://blog.x2go.org/index.php/2012/07/26/x2go-sessions-startups-for-users-w... this should have been fixed a while ago, but it seems to have returned.
The mentioned change is very old and relied on executing "sh". We've seen users changing this to non-bash compatible shells in the past, so it didn't fix all issues.
I couldn't see any difference neither in the server log (debug level) nor in the output of "x2goclient --debug". The clients are identical until the line
x2go-DEBUG-../src/onmainwindow.cpp:6014> Proxy wrote on stderr: "Session: Session started at 'Fri Oct 6 16:43:09 2017'.
and then the tcsh instance exits with Warning: Protocol mismatch or no X authentication data.
while the bash version continues with x2go-DEBUG-../src/onmainwindow.cpp:6014> Proxy wrote on stderr: "Info: Established X server connection.
The server logs are identical until the line 2017-10-06T16:43:09.173981+02:00 knuth /usr/lib/x2go/x2gocreatesession[21667]: db_createsession called, session ID: fst-76-1507300986_stDmwm_dp24, cookie: 7b94de4d7f6bdbcda01a3dc547c42f66, client: xx:xx:xx:xx, pid: 21620, graphics port: 35760, sound port: 35761, file sharing port: 35762
and then the tcsh instance exits with 2017-10-06T16:43:15.007175+02:00 knuth sshd[21228]: pam_unix(sshd:session): session closed for user fst 2017-10-06T16:43:15.011998+02:00 knuth systemd-logind[9940]: Removed session 59.
Yeah, because nxagent died or wasn't started correctly, so the session terminates.
Is this problem known already? Sth. I could try to solve it? We wouldn't like to force all our users to switch away from their tcsh...
No, but I guess I know what the problem is. Quoting in bash and tcsh is different (esp. nested double quotes, which don't work by default in tcsh but is a special option), so some (or all) commands might not be getting executed correctly.
I guess we'll need a more sophisticated approach that executes bash directly once and then uses a bash instance to parse the command line instead of letting the user's default shell handle parsing the initial command.
Sorry, I can't offer a workaround. It's just buggy currently.
Mihai