On 11/03/2017 07:58 PM, Robert Kudyba wrote:
On another server that works OK I just killed an X2Go session from August! student 21855 0.0 0.0 151456 632 ? S Aug31 0:23 /usr/lib64/nx/../x2go/bin/x2goagent -extension XFIXES -nolisten tcp -nolisten tcp -dpi 120 -D -auth /home/students/student/.Xauthority -geometry 800x600 -name X2GO-student-50-1504212607_stDKDE_dp32 :50
Yeah, for successfully started sessions, that's probably not happening because they use the "normal" running -> [ suspended -> running -> ... ] -> terminated scheme. Only sessions failing very early might be problematic, though I haven't yet understood why the DB is not being cleaned up in this error case. Normally sessions should start at DISPLAY 50 and take the first one that is free - for the machine that fails to spawn sessions, you're already at display number 150, which suggests that stale/failed sessions are still recorded in the database and not cleaned up like they should be.
Can I provide anything else? Could NIS be contributing to this?
A VM that reproduces this problem would be great, although that's not something I can ask from you, since there are so many outside dependencies like the NIS setup that can't be easily reproduced.
I was under the impression that NIS doesn't play a role in this, assuming that the working F26 machine also uses NIS, but it might be correlated.
It fails with NIS users and local users. On the working and non-working machine, I try with a local user and both $HOME are set as follows: echo $HOME /home/localguy
That's normal. When you did the plain xauth/nxagent tests I requested a few mails ago, did you test with a NIS user?
I've seen something non-standard in there, namely:
xauth Using authority file /u/erdos/myuser/.Xauthority
This suggests that the X authority file is set via the XAUTHORITY variable (echo $XAUTHORITY) to a path that isn't located relative to $HOME but lives on a remote server, that likely can be reached via NFS. This probably makes sense in your setup, since that way you can provide a global Xauthority file for users that is "shared" between all machines users log in, but could also be problematic for X2Go/NX.
Both nxproxy and nxagent try to query the X authorization cookie by doing an xauth call, but override the default file path (which would be $HOME/.Xauthority
- and probably not work in your setup) *and* the variable that overrides the default file path ($XAUTHORITY - which probably would work in your setup) with an explicit -f parameter again. Either with the value of $XAUTHORITY or $HOME/.Xauthority, if the former is not set. x2gostartagent explicitly exports XAUTHORITY with either the already set value or otherwise with $HOME/.Xauthority. In general the value shouldn't be relevant, as long as its used consistently and this seems to be the case.
We've also tried to use a plain-vanilla .bashrc and .bash_profile, no difference.
Could there be any other installed package causing a conflict?
This also fails from a PC 4.1.0.0 client, BTW some logs:
Yeah, not surprising, since it's really a server-side problem.
I haven't asked for that yet, I guess, but it might be interesting to see what the nxagent server process actually logged. On the server side, ~/.x2go/C-* should contain a session.log file.
Mihai