[X2Go-Dev] new version 4.1.1.0 from Mac still crashes to Fedora 26

[Mihai Moldovan]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20171104/95850812/attachment.sig>