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

[Nick Couchman]

>>> On 2013/01/19 at 10:18, <chris at ccburton.com> wrote: 
> freenx-knx-bounces at kde.org wrote on 19/01/2013 16:23:38:
> 
>> > 
>> > It might be timing i.e nxagent hasn't had time to start
>> >          rather than it can't because :11000 is in use
> 
> Maybe, but agent also runs when you run xterm which you say works every 
> time . . 

...which indicates to me that it's some sort of timing issue - that xterm is a very simple request for nxagent to start, and that something about the window manager is either timing out or causing nxagent to crash or something similar.

> 
> 
>> > 
>> > 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 ??
>> > 
>> > 
>> 
>> So, changing the display base to 2500 did not help.  Don't think 
>> that's the issue.
> 
> 
> The issue you have is that nxagent won't start (on :11000)
> or
> if it does it won't keep running 'cos it can't open the display :11000

But it isn't just :11000, it's :2500 or :1000 or :3000, etc. - so it's not anything specific to the display base.

> 
>> Error: Aborting session with 'Unable to open display 
> 'nx/nx,options=/home/nxtest/.nx/C-se003945-11000-7CE6ABAB93B40AE2CB8303E679FBE3
> 9C/options:11000''.
> 
> **** OR ****
> 
> nxagent is running on :11000
> and
> your 
>         startxfe4
> 
>  is trying to start YET ANOTHER X on :11000
> 
>> xrdb: Can't open display ':11000'
>> /usr/bin/startxfce4: X server already running on display :11000
>> xrdb: Connection refused
> 
> which would explain why xterm works.
> 
> *** Try running an xterm and run startkde within the xterm ***

Already did this, and I am able to successfully log in with an xterm and startxfce4 (or startkde, etc.).  I get the same message when I do that about "X server already running on display", so I'm guessing the startxfce4 script just has a routine that checks for X and starts it if it isn't running.  So, I don't think this is the issue.  Something with timing between nxagent and any of the login managers.

> 
> 
> 
> 
>> Error: Failure negotiating the session in stage '10'.
> 
> try
>          grep -i stage /usr/bin/nx*
> 
> 
> 
> What is in the server log just before all this . . .
> 
>> - 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

Just before that:

nxnode_reader: NX> 1000 NXNODE - Version 3.2.0-73 OS (GPL, using backend: 3.5.0)
NX> 1000 NXNODE - Version 3.2.0-73 OS (GPL, using backend: 3.5.0)
server_nxnode_echo: NX> 1000 NXNODE - Version 3.2.0-73 OS (GPL, using backend: 3.5.0)
nxnode_reader: NX> 700 Session id: se003945-13945-B0402B1D28DECFB44617E9BB4EDC80D9
nxnode_reader: NX> 705 Session display: 13945
nxnode_reader: NX> 703 Session type: unix-gnome
nxnode_reader: NX> 701 Proxy cookie: b7b9773bdd9fad3a2d3f489da542d7ca
nxnode_reader: NX> 702 Proxy IP: 127.0.0.1
nxnode_reader: NX> 706 Agent cookie: b7b9773bdd9fad3a2d3f489da542d7ca
nxnode_reader: NX> 704 Session cache: unix-gnome
nxnode_reader: NX> 707 SSL tunneling: 1
nxnode_reader: NX> 709 File-sharing port: 445
NX> 700 Session id: se003945-13945-B0402B1D28DECFB44617E9BB4EDC80D9
NX> 705 Session display: 13945
NX> 703 Session type: unix-gnome
NX> 701 Proxy cookie: b7b9773bdd9fad3a2d3f489da542d7ca
NX> 702 Proxy IP: 127.0.0.1
NX> 706 Agent cookie: b7b9773bdd9fad3a2d3f489da542d7ca
NX> 704 Session cache: unix-gnome
NX> 707 SSL tunneling: 1
NX> 709 File-sharing port: 445
server_nxnode_echo: NX> 700 Session id: se003945-13945-B0402B1D28DECFB44617E9BB4EDC80D9
server_nxnode_echo: NX> 705 Session display: 13945
server_nxnode_echo: NX> 703 Session type: unix-gnome
server_nxnode_echo: NX> 701 Proxy cookie: b7b9773bdd9fad3a2d3f489da542d7ca
server_nxnode_echo: NX> 702 Proxy IP: 127.0.0.1
server_nxnode_echo: NX> 706 Agent cookie: b7b9773bdd9fad3a2d3f489da542d7ca
server_nxnode_echo: NX> 704 Session cache: unix-gnome
server_nxnode_echo: NX> 707 SSL tunneling: 1
server_nxnode_echo: NX> 709 File-sharing port: 445
nxnode_reader: NX> 710 Session status: running
NX> 710 Session status: running
server_nxnode_echo: NX> 710 Session status: running
nxnode_reader: NX> 1002 Commit
NX> 1002 Commit
server_nxnode_echo: NX> 1002 Commit
nxnode_reader: NX> 1006 Session status: running
NX> 1006 Session status: running
server_nxnode_echo: NX> 1006 Session status: running
NX> 105 bye

> 
> 
> Clean up any/all the nx processes on your server and start again
> with a new connection.
> 
> If the session falls over, look to see what is still running.
> Is something holding on to display :11000

I've done that a couple of times - I am quite confident there is nothing left running on these ports that is interfering.  Besides that, the random successes that I get don't really point to this - I can try 10 times in a row and it'll fail all except once, and that once could be the 2nd time or the 6th time or the 10th time - there's no reason to it.

Thanks - Nick



--------
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.