[FreeNX-kNX] FreeNX & NoMachine Player - Connection Issues

Sat Jan 19 16:15:21 UTC 2013

>>> On 2013/01/19 at 04:57, <chris at ccburton.com> wrote: 
> freenx-knx-bounces at kde.org wrote on 19/01/2013 03:17:26:
> 
> 
> NoMachine player should of course connect to v3 OK
> but
> it is a lower priority for nomachine than getting v4 out . . .
> 
> your best bet is probably to try Fritz (et alii)'s OpenNX client
>         for Mac
> 
>  

First, we've tried OpenNX and not been overly successful getting it running.  Second, because NX Player seems to work fine with FreeNX on CentOS, NX Server 3.5, and the NoMachine 4 Preview, I think the client is not the issue and that NX Player should work fine.  I suspect the issue is in the FreeNX + OpenSuSE combo.

> 
> 
> Note FYI
> 
> There is an open "X" font rendering bug between
>          OpenSuse 12.2 and the Nomachine Windows client
> which
>          the OpenNX cliient doesn't have . . . 
> 
> so Nomachine aren't worrying too much about Suse

Hmmm...we haven't run into this one, yet.

> 
> 
> If you mean to USE OS-X you really should TEST/FIX on OS-X
>         else you may have it all to do again . . 

Understood,  but since I don't think the client is the issue, I don't think this matters.  Also, while OS X is one of the key requirements, it also needs to work from Linux and Windows, it's just that Linux and Windows are the two O/Ss that already have 3.5 clients that I could use, instead, while OS X only works with NX Player.

> 
> 
> Do you have FreeNX AND Nomachine V4 on the same Suse machine ??
> 
> Do you have connections to both at the same time ???
> 
> Is thete any overlap of resorces . . .

No x 3.  I have identical SuSE systems (openSuSE 12.1) that I'm trying to connect to.  Once has NoMachine 4 Preview, the other has FreeNX.  NX Player connects to the Preview fine, but not to FreeNX on openSuSE.

> 
> 
>> what, or at least help me better nail it down.  Here's what I'm seeing:
>> 
>> - Connections fail *most* of the time - maybe 1 connection in 10 
>> works perfectly fine, but the rest fail with the exact same error.
>> - It does not matter what Window Manager I try to use - KDE4, XFCE4,
>> GNOME - all seem to fail equally well.
>> - This is not trying to resume an existing session, just create a new 
> one.
>> - I've tried local users and network users on my systems, and that 
>> doesn't really seem to make a difference, either, so not a home 
>> directory, LDAP, or NFS issue.
>> - I see the following message on the screen on NXPlayer when I try 
>> to create a new, GNOME, for example, session:
>> The connection with the server was lost.
>> Error is 22: Invalid argument.
>> 
>> - If I choose the option to save the logs and then go look at the 
> [SNIP]
>> 28343 5201 19:57:45 291.001 ProxySession/Threadable: Restoring 
>> context from threadable 0xb4e28c60.
>> 28343 5201 19:57:45 291.064 Entropy:       FM T 0 
>> Session: Session terminated at 'Fri Jan 18 19:57:45 2013'.
>> 28343 5201 19:57:45 291.234 ClientTransResetCallback: WARNING! The 
>> NX transport terminated with error '22' 'Invalid argument'.
>> 28343 5201 19:57:45 291.250 Dispatcher: ERROR! Bad pointer '0' in 
>> method 'Dispatcher::removeObject()' context [A].
> 
> 
> Something went wrong . . .
> 
> ( after it got a "bye" from FreeNX as a "remote option" (so it thought) 
>                 and the ssh session stopped  )
> 
> 
> Strange that it would work at all unless . . .  see a bit later  . . .
> 
> 
>> Error: Bad pointer '0' in method 'Dispatcher::removeObject()' context 
> [A].
>> 28343 28343 19:57:45 329.305 ClientSession: Exiting from the client 
>> transport loop.
>> 28343 28343 19:57:45 329.362 ClientSession: The transport closed 
>> with reset '1' error '22'.
>> 28343 28343 19:57:45 329.395 ClientSession: Session at 0x82cff28 failed.
>> 28343 28343 19:57:45 329.413 ClientSession: Failing reason is 'The 
>> connection with the server was lost.
>> 
>> Error is 22: Invalid argument.'.
>> 
>> - If I look at the logs on the server (with logging turned up a bit), I 
> see:
>> bye
>> Bye
>> NX> 999 Bye
>> Info: Closing connection to slave with pid 27540.
>> nxnode_reader: 1001 Bye.
>> 1001 Bye.
>> nxnode_reader: NX> 1004 Error: NX Agent exited with exit status 1. 
>> To troubleshoot set SESSION_LOG_CLEAN=0 in node.conf and investigate
>> "/home/nxtest/.nx/F-C-
>> se003945-11000-7CE6ABAB93B40AE2CB8303E679FBE39C/session". You might 
>> also want to try: ssh -X myserver; /usr/bin/nxnode --agent to test 
>> the basic functionality. Session log follows:
>> NX> 1004 Error: NX Agent exited with exit status 1. To troubleshoot 
>> set SESSION_LOG_CLEAN=0 in node.conf and investigate "/home/nxtest/.
>> nx/F-C-se003945-11000-7CE6ABAB93B40AE2CB8303E679FBE39C/session". You
>> might also want to try: ssh -X myserver; /usr/bin/nxnode --agent to 
>> test the basic functionality. Session log follows:
>> nxnode_reader: NX> 1006 Session status: closed
>> NX> 1006 Session status: closed
>> server_nxnode_echo: NX> 596 Session startup failed.
>> NX> 596 Session startup failed.
>> server_nxnode_echo: NX> 1004 Error: NX Agent exited with exit status
>> 1. To troubleshoot set SESSION_LOG_CLEAN=0 in node.conf and 
>> investigate "/home/nxtest/.nx/F-C-
>> se003945-11000-7CE6ABAB93B40AE2CB8303E679FBE39C/session". You might 
>> also want to try: ssh -X myserver; /usr/bin/nxnode --agent to test 
>> the basic functionality. Session log follows:
>> session_close 7CE6ABAB93B40AE2CB8303E679FBE39C
>> server_nxnode_echo: NX> 1006 Session status: closed
>> nxnode_reader: NX> 1001 Bye.
>> NX> 1001 Bye.
>> server_nxnode_echo: NX> 1001 Bye.
>> Info: Closing connection to slave with pid 27540.
>> 
>> - Finally, if I look at the user-specific logs mentioned, I see:
>> Error: The remote NX proxy closed the connection.
>> Error: Failure negotiating the session in stage '10'.
>> Error: Aborting session with 'Unable to open display 'nx/nx,
>> options=/home/nxtest/.nx/C-
>> se003945-11000-7CE6ABAB93B40AE2CB8303E679FBE39C/options:11000''.
>> Session: Aborting session at 'Fri Jan 18 19:57:45 2013'.
>> Session: Session aborted at 'Fri Jan 18 19:57:45 2013'.
>> xrdb: Connection refused
>> xrdb: Can't open display ':11000'
>> /usr/bin/startxfce4: X server already running on display :11000
> 
> already running . . . XAuth issue probably
> 
> 
> Update the FreeNX server
> 
>                 #DISPLAY_BASE=1000  ( or whatever. if it's # ed out, the 
> value is set by nxloadconfig )
>                 DISPLAY_BASE=(your value)
> 
> parameterin /etc/nxserver/node.conf
> 
> and try a value other than 11000 or 1000

Okay, I will try that, but I think I've tried a few other values there and nothing seems to make a difference.  I'll try something in the 2000-5000 range or something like that to see if that helps.

> 
> 
>> xrdb: Connection refused
>> xrdb: Can't open display ':11000'
>> xscreensaver: 19:57:45: Can't open display: :11000
>> xscreensaver: 19:57:45: running as nxtest/users (120/100)
>> 
>> xscreensaver: 19:57:45: Errors at startup are usually authorization 
> problems.
>>               But you're not logging in as root (good!) so something
>>               else must be wrong.  Did you read the manual and the FAQ?
>> 
>>               http://www.jwz.org/xscreensaver/faq.html
>>               http://www.jwz.org/xscreensaver/man.html
>> 
>> 
>> ** ERROR **: Cannot open display: 
>> /etc/xdg/xfce4/xinitrc: line 159: 28167 Trace/breakpoint trap 
> xfce4-session
>> 
>> 
>> So, can anyone shed any light on what's going on here??  First, it 
>> seems like the server and client are both pointing the finger at 
>> each other saying it's the other's fault.  But then there's this 
>> error about Unable to open display??  I should also note that I have
>> tried and successfully been able to do the "ssh -X <hostname> 
>> nxagent" test - works fine, once it's running I can open up items 
>> inside that display, etc.  Also, on NXPlayer, if I do a custom 
>> session and specify xterm as the command to run, that seems to work 
>> every time.  So, perhaps it's a timing thing - the window manager 
> 
> It might be timing i.e nxagent hasn't had time to start
>          rather than it can't because :11000 is in use

:11000 isn't in use by anything else on the system - I did check that.

> 
> Test . . .
> If you try a number of connections one after the other
>         does it fail to connect a few times
>         then connect eventually
>         and keep connecting if you disconnect/re-cconect
>         a few times ??

Yes, if I continue to try it over and over, I'll eventually get a good session.  It doesn't seem to matter how rapidly I disconnect/reconnect, it just works 1/10 times or something like that (random, I'm sure - it isn't *exactly* 1/10 times, just roughly in that area).  I didn't try the disconnect/reconnect (suspend/resume), yet, but I'll give that a shot - I was just trying to get the basic connection working before I got to the other complications :-).

> 
> 
>> trying to start before X is available, or maybe X is timing out too 
>> fast before the window manager can start?  Also, what happens in 
>> "Stage '10'"?  This is a fairly consistent error - failure 
>> negotiating the session in stage '10' - but I cannot find any 
>> reference to this error around, nor can I figure out what stage 10 
>> is supposed to be.
>> 
>> Thanks, in advance,
>> Nick
> 
> 
> Let us know how you get on . . .
> 
> 
> 
> London is snowed in ( well 2" ) this weekend, so I'm working a saturday . 
> . .

Well, we're not snowed in here in Denver, but I'm working a Saturday anyway :-).

--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient.  If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information.  In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way.  If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox.  Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.