Re: problem with XQuartz 2.5.0_rc1 and NoMachine NX
Re: problem with XQuartz 2.5.0_rc1 and NoMachine NX
- Subject: Re: problem with XQuartz 2.5.0_rc1 and NoMachine NX
- From: Jeremy Huddleston <email@hidden>
- Date: Wed, 17 Mar 2010 13:32:07 -0700
They probably "fixed" it in a way that was not equivalent to the way libX11, libxcb, and ssh find the socket.
As a workaround, you can probably just use the traditional DISPLAY value with NX. Do this from a terminal:
ps x | grep bin/X
Look for this line:
57954 ?? S 0:00.01 /opt/X11/bin/X :5 -dpi 96
the ":5" is what is important there. Try starting NX as:
DISPLAY=:5 /path/to/NX/executable
--Jeremy
On Mar 17, 2010, at 11:57, Scott Classen wrote:
> I do not have a paid subscription to any of NoMachine's products so I am unable to file a bug report.
>
> Searching their website turned up the following technical report (Trouble Report #TR11G02292 - http://www.nomachine.com/tr/view.php?id=TR11G02292):
>
>> The session may fail with error 'Can't determine the location of the X display socket'
> <1pixtransp.gif>
>>
>> NX client creates the NX_TEMP environment variable to point to the base directory where the X11 Unix Domain Sockets and all temporary files are created.
>>
>> In order to determine this directory, nxclient reads the TEMP environment variable value.
>>
>> Since a connection problem may occur if this directory doesn't contain the .X11-unix/ directory, a validation check should be executed before using it to change the NX_TEMP value.
>>
>> This problem only affects Unix systems.
>>
>> As workaround a wrapper script can be used in order to unset the TEMP variable before executing the nxclient binary.
>
>
> They claim the problem was fixed in the 3.4.0-7 patch, so perhaps this isn't exactly the same problem I'm experiencing, but I thought I'd report back to this list in case anyone has other ideas or perhaps has an account with NoMachine and could file a bug report on our behalf.
>
> Thanks,
> Scott
>
>
> On Mar 17, 2010, at 10:36 AM, Chris Jones wrote:
>
>>
>>> That's certainly it then. They probably rolled their own patch to ssh rather than using the one from Apple. Please contact them and let them know they should fix the problem. I'm not sure why they didn't just use the patch from Apple (or just use our /usr/bin/ssh)...
>>
>> As far as I understand it they have to use their own patched ssh version in order to implement the clever X compression technology they use, so using /usr/bin/ssh is not an option I think. But I'm not an expert. Probably it is discussed somewhere on their web site. Whatever it is they do it works - Its a *lot* faster than just piping a standard X window through a standard ssh connection, or even things like vnc.
>>
>> I agree NX probably just need to update their 'apple' patch ...
>>
>> Given this issue, I have no plans to try out XQuartz 2.5.0_rc1 as working with NX is my main use case ;). So hopefully the original OP will be able to gather the information themselves to make a report back to NX ?
>>
>> cheers Chris
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> X11-users mailing list (email@hidden)
>>
>> This email sent to email@hidden
>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden