On 11/02/2017 08:57 PM, Robert Kudyba wrote:
Yes.
That's weird, it sounds like sessions are accumulating in the database, but not printed out. This shouldn't happen, since sessions in the failed state should be automatically removed when executing this program (and also indirectly through this mechanism by x2gocleansessions.)
Probably not something you are likely to run into a hard limit with, but we should keep that mind.
rpm -q x2goserver x2goserver-4.1.0.0-0.0x2go1.0.git20171102.1437.heuler.fc26.x86_64
Takes several seconds but eventually quits and here are the errors/logs:
Okay, better, although we're pretty much back at square one.
x2go-DEBUG-../src/onmainwindow.cpp:6372> Proxy wrote on stderr: "Warning: Failed to read data from the X auth command. Warning: Generated a fake cookie for X authentication.
That's a long-standing issue on OS X. Since the launchd infrastructure is used for spawning X sockets (and clients connecting through that), nxproxy was never able to query the real X authorization cookie correctly.
I'll fix that up, now that I took a look at the code anyway as part of trying to understand what is going on in your case.
Anyway, this shouldn't be a real issue - the generated fake X cookie should be good enough for establishing connections. Given that you can spawn sessions to the other server machine, that seems to be the case in general.
The issue should be gone in the current nightly build: https://code.x2go.org/releases/X2GoClient_nightly_macosx/x2goclient-4.1.1.1....
I don't expect that to fix your issue, though.
Warning: Protocol mismatch or no X authentication data.
This is the really bad sign - the X authorization cookie received from the server couldn't be verified correctly. It's expecting to see "MIT-MAGIC-COOKIE-1" in the received data, but that doesn't seem to be the case.
That, again, hints at the server side not correctly inserting the cookie for some reason (or alternatively not being able to read it again when nxagent is trying to send it to the client-side proxy.)
It's very difficult for me to debug it that way, though. It would really help to be able to reproduce that issue.
It looks like your $HOME path is a bit unusual, is that also the case on the machine that works? I assume $HOME is set correctly? (Given from your interactive shell examples, I assume that to be true.)
Mihai