Hello Stefan
I did indeed try the things you suggested with the same results. After comparing releases on a machine where things work and this one I found that elsewhere x2go was installed from the x2go-release-epel repository while on the broken one it was the epel repository version:
x2goserver: 4.1.0.2 x2goserver-common: 4.1.0.2 x2goserver-extensions: 4.1.0.2 x2goserver-x2goagent: 3.5.99.16 x2goserver-xsession: 4.1.0.2
vs.
x2goserver: 4.1.0.0 x2goserver-common: 4.1.0.0 x2goserver-extensions: 4.1.0.0 x2goserver-x2goagent: 3.5.99.16 x2goserver-xsession: 4.1.0.0
I removed all packages and dependencies and installed the new version. This works. Apparently there is some sort of bug in the older version that prevents the initialization of new user sessions because diverse testusers which had never logged in and never used x2go ran into the same problem.
Interestingly enough, a user with a previously functioning session (which did not get removed) worked.
Greetings Daniel
On 10/17/2018 04:01 PM, Stefan Baur wrote:
Am 17.10.18 um 15:46 schrieb Daniel Kollmer:
I don't see any x2go processes running.
I have compared the debug log of this machine with one where things work, and it seems to me that this message is where things break:
x2go-DEBUG-../src/sshprocess.cpp:532> Have stderr only, something must be wrong
I don't see that on other machines where the client just breezes past this point. Not sure what I should make of it though. What happens when you create a test account on the same server, and try to log in to that? Same error, or working fine?
If it's only the single account that is affected, and not the entire server, my gut feeling would be that the user didn't just delete some session data, but messed with some configuration file, maybe .profile or .bash_rc. Look if any of those contains a redirect (>) instruction, maybe some ">/dev/null" somewhere that has become dangling.
Some more things to try:
Can the affected user log in via plain ssh? What about the test user?
Assuming logging in via plain ssh works, what happens when the affected user logs in via plain ssh and runs:
x2golistsessions
Also, the output of
dpkg -l | egrep 'nx|x2go'
might provide some clues.
Kind Regards, Stefan Baur
-- Daniel Kollmer Computer Technology Group NIKHEF - Dutch National Institute for Sub-atomic Physics Science Park 105 1098 XG Amsterdam Phone: +31205922164