NoMachine NXclient NXLogin::reset

Quantumstate · 01-27-2011, 12:34 PM

I've used NoMachine's NX software for some time, but on one of my machines it simply will not work. At first it did, but now when I log in it authenticates, starts downloading a session, but then drops dead. There is no hint of what the problem may be except in /var/log/messages on the server machine:

User 'bill' from '192.168.1.1' logged out. 'NXLogin::reset'

Notice that it's a login reset, after authentication went fine. Researching this I find the problem is often caused by a missing fixed font, which is remedied with an:
# apt-get install xfonts-base --reinstall
... but that doesn't help.

I have completely deinstalled and purged the three Nomachine packages on the server, deleting all associated directories, and reinstalled them, but no help. From my client machine I can log into a NX session just fine, so I'm sure it's not the client machine.

The Linux version of this software has a limit of 2 sessions, and I suspect the server may have some bogus sessions open, but where? I've done a purge and deleted /usr/NX and /home/bill/.nx so where else could this be?

sys64738 · 01-27-2011, 04:10 PM

Hi

maybe you have problems with "left over" session (caused by network and/or client problems).
There is a "NX Session Administrator" you can call that and check.

If not (or anyway) you could use freeNX as Server. Have a look here:
http://freenx.berlios.de/
It is free and doesn't have session limits.

I'd recommend use the NX client and freeNX Server.

Noway2 · 01-28-2011, 04:12 AM

I agree that there is probably some session garbage and my guess would be in /var somewhere, e.g. /var/lib/nxserver/db/running/ (from some searching).

I haven't used FreeNX in a while, but I used it a lot at the place I last worked. As a temporary work around when you start getting, you can create a new session on the client (but there may be the session limit). I have found that the problem occurs if you simply close out the session window or terminate the session, without 'logging off' as can happen if you shut down the client without logging out of the remote host first.

Quantumstate · 01-28-2011, 12:18 PM

Thanks. I'd considered FreeNX, but it seems development has all but stopped over the past couple years, I guess because of the availability of the official NX.

Maybe by 'NX Session Administrator' you mean /usr/NX/bin/nxclient --admin which shows the sessions. On the client machine (hex) I see the running session, but the failed one on gemini (server) shows Closed. Looking at the log it says:

Code:

NXPROXY - Version 3.4.0

Copyright (C) 2001, 2010 NoMachine.
See http://www.nomachine.com/ for more information.

Info: Proxy running in client mode with pid '25809'.
Session: Starting session at 'Fri Jan 28 08:04:27 2011'.
Info: Connection with remote proxy completed.
Info: Using LAN link parameters 1536/24/1/0.
Info: Using pack method 'adaptive-9' with session 'kde'.
Info: Using product 'LFE/None/LFEN/None'.
Info: Not using NX delta compression.
Info: Not using ZLIB data compression.
Info: Not using ZLIB stream compression.
Info: Not using a persistent cache.
Info: Forwarding X11 connections to display ':0'.
Info: Forwarding multimedia connections to port '6000'.
Info: Listening to font server connections on port '11015'.
Session: Session started at 'Fri Jan 28 08:04:27 2011'.
Info: Established X server connection.
Info: Using shared memory parameters 1/2048K.
Session: Terminating session at 'Fri Jan 28 08:04:33 2011'.
Session: Session terminated at 'Fri Jan 28 08:04:33 2011'

... not very helpful. I've found the Support article on the Nomachine site that shows where errors are reported on the server: /home/{user}/.nx/F-* or C-* or T-* and it does create a C-* dir, but then summarily deletes it for some reason. In server://$HOME/.nx I only have a cache-kde directory, which is empty.

The only other place where errors are reported is in /var/log/messages and syslog on the server. I've found the NoMachine KnowledgeBase article on how to tweak up error reporting on the server and did that, so now in /var/log/syslog there is a massive amount of info generated. From that it appears that the only lock files are in /usr/NX/etc, on each .db file. These were there even after I stopped the NX server so I deleted all the .lock files, but it didn't help.

I've done a case-insensitive search on the server of /lib and /var for nx* and only came up with the dpkg install. Of course searching in /usr comes up with everything in the NX directory. I don't see anything that remotely looks like a pid file; of course they wouldn't want us to know how to find this session tracking, but I don't know what more to do than delete /usr/NX and $HOME/.nx . This is Debian.

Well now I've pored through the pages of messages in syslog related to my failed NX session. I tried each command it did during the setup, but for /usr/NX/bin/nxagent it complained that libXcomp.so.3 is missing (libxcomp3 - NX X compression library) so I installed it but it didn't help. As far as I can tell from all the syslog messages, I am being logged out while the session is still being set up. Here's the relevant section:

Code:

Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: Sent response message: 700, with parameters: 'gemini-1016-A1EB2D1B64DE0561A989038870432193' main::send_response_message nxnode 6180
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: received data in out channel from NX Node: 'NX> 700 Session id: gemini-1016-A1EB2D1B64DE0561A989038870432193\n' (NXNodeExec). Stored status. 'Logger::$
Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: Sent response message: 705, with parameters: '1016' main::send_response_message nxnode 6181
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: No registered handler function for message: '700' 'NXNodeExec::__onMessageRun'
Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: Sent response message: 703, with parameters: 'unix-kde' main::send_response_message nxnode 6182
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: received data in out channel from NX Node: 'NX> 705 Session display: 1016\nNX> 703 Session type: unix-kde\n' (NXNodeExec). Stored status. 'Logger::sta$
Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: Sent response message: 701, with parameters: 'BC328960F1F5252F0BBA349DD1A92401' main::send_response_message nxnode 6183
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: No registered handler function for message: '703' 'NXNodeExec::__onMessageRun'
Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: Sent response message: 702, with parameters: '192.168.111.4' main::send_response_message nxnode 6184
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: No registered handler function for message: '705' 'NXNodeExec::__onMessageRun'
Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: Sent response message: 706, with parameters: 'BC328960F1F5252F0BBA349DD1A92401' main::send_response_message nxnode 6185
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: received data in out channel from NX Node: 'NX> 701 Proxy cookie: BC328960F1F5252F0BBA349DD1A92401\nNX> 702 Proxy IP: 192.168.111.4\nNX> 706 Agent coo$
Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: Sent response message: 704, with parameters: 'unix-kde' main::send_response_message nxnode 6186
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: No registered handler function for message: '706' 'NXNodeExec::__onMessageRun'
Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: Sent response message: 728, with parameters: 'NX - bill@localhost:1016 - Gemini' main::send_response_message nxnode 6187
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: No registered handler function for message: '701' 'NXNodeExec::__onMessageRun'
Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: Sent response message: 707, with parameters: '1' main::send_response_message nxnode 6192
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: No registered handler function for message: '702' 'NXNodeExec::__onMessageRun'
Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: Sent response message: 708, with parameters: 'LFE/None/LFEN/None' main::send_response_message nxnode 6213
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: received data in out channel from NX Node: 'NX> 704 Session cache: unix-kde\nNX> 728 Session caption: NX - bill@localhost:1016 - Gemini\nNX> 707 SSL t$
Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: Sent response message: 710, with parameters: 'running' main::send_response_message nxnode 6215
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: No registered handler function for message: '708' 'NXNodeExec::__onMessageRun'
Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: Sent response message: 1007, with parameters: '' main::send_response_message nxnode 6216
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: No registered handler function for message: '704' 'NXNodeExec::__onMessageRun'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: No registered handler function for message: '707' 'NXNodeExec::__onMessageRun'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: received data in out channel from NX Node: 'NX> 710 Session status: running\nNX> 1007 Commit and close FH\n' (NXNodeExec). Stored status. 'Logger::sta$
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: received message 'COMMIT2' from NX Node (NXNodeExec). Stored status. 'Logger::statusPush'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: returning to interactive mode (NXNodeExec). Stored status. 'Logger::statusPush'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8210]: DEBUG: run command: cleared child set 'main::__reset_process_to_wait'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8210]: DEBUG: waiting for message 'BYE' from NX Node (NXNodeExec). Stored status. 'Logger::statusPush'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8210]: DEBUG: Calling handler function: 'NXUtmp::add' for 'connected to nxnode' event 'NXNodeExec::__onMessageRun'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: Session 'A1EB2D1B64DE0561A989038870432193' started by user 'bill'. 'NXShell::handler_session_start'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8210]: DEBUG: NXutmp logging disabled. 'NXUtmp::add'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: Server pid for session 'A1EB2D1B64DE0561A989038870432193' is: 8210 'NXShell::handler_session_start'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: SCRIPTS:: script_after_start_session [A1EB2D1B64DE0561A989038870432193,bill,localhost,22] 'NXScripts::script_after_start_session'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8210]: DEBUG: Handler function finished 'NXNodeExec::__onMessageRun'
Jan 28 08:36:32 gemini NXNODE-3.4.0-14[8184]: DEBUG: run command: trying to run command 'mv /home/bill/.kde/share/config/knotifyrc.nxsaved /home/bill/.kde/share/config/knotifyrc' (eval) nxnode 3330
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: received command 'bye' '' 'NXShell::get_command'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: handling command 'bye' '' 'NXShell::handle_command'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: Running nxssh for forwarding session 'NXShell::handler_bye'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: DEBUG: nxssh is now running with pid: 8212 'NXShell::handler_bye'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8212]: DEBUG: run command: cleared child set 'main::__reset_process_to_wait'
Jan 28 08:36:32 gemini NXSERVER-3.4.0-14[8159]: User 'bill' from '192.168.111.1' logged out. 'NXLogin::reset'

For some reason I am being logged out, after having been authenticated, while the session is still setting up. Once the session is set up it discovers I've been logged out and tears down.

Quantumstate · 02-02-2011, 07:08 AM

No ideas? Anyone know of an irc or listserv?

sys64738 · 02-02-2011, 04:57 PM

If you want support for the official nx software goto:
http://www.nomachine.com/support.php

Quantumstate · 02-03-2011, 10:31 AM

Sure, but they charge for that. I'm looking for web support but can't find it.

essensium · 02-09-2011, 04:00 PM

They have just released an MR, it might fix the problem. The announcement is on their home page.

Ess.

Quantumstate · 02-10-2011, 12:43 PM

I did end up sending an email to Support, and they responded:

Quote:

Hello,

Thank you for contacting us.

We are aware of this thread and we are happy to accept bug reports from all our users whether NX Free Edition or subscription users.

This particular bug should be fixed with the following implementation

- Improving the creation of links to the run level directories for starting and stopping the NX server services
http://www.nomachine.com/fr/view.php?id=FR11G02291

Our developers are working to implement this for a successive maintenance release of NX 3.4.0. We advise you to sign up to one of our mailing lists NX Announce or NX News to receive the latest news concerning software updates and what these updates include.

For any other issues, please send in details of NX versions, environment and specific steps to reproduce. Our developers will queue up for investigation and open the necessary Trouble Reports or Feature Requests.

Kind regards,

The NoMachine Team

So, good news. Maybe the fix is in this MR; says it is in the release notes.. I'll try it. Only question is wh-wh-what took them so long? Why did the problem have to get so debilitating?

Quantumstate · 02-11-2011, 04:34 PM

Ah, the new version fixed the apt-get problem, but no the auto-signout one which is the topic of this thread.

astephan2525 · 02-23-2011, 08:33 AM

I'm having the same problem, any solutions yet? Maybe I'll just try to install an older version of NX... if I can find one.

Quantumstate · 02-24-2011, 12:05 PM

Nomachine says there's something wrong with my KDE. As it's a headless server, I'll have to drag out a display and keyboard to check it out.

Quote:

Looking at the logs we can see that /etc/X11/Xsession startkde stops after 2 seconds. Before and after that, no errors or problems are picked up by nxclient, nxnode and nxserver whatsoever. Furthermore, Xsession does not print any error message on stderr.

So you should check why KDE is dying immediately by debugging the command "/etc/X11/Xsession startkde".

You can set the 'startkde' command directly in the node configuration file (COMMAND_START_KDE configuration key), or add strace there to see where Xsession or KDE fail.

It does not look to be a problem of DB locking, but rather an issue with KDE on your system.

The following article can be used as a reference:

- What to do if running a KDE session fails with the error 'Cannot run startkde'
http://www.nomachine.com/ar/view.php?ar_id=AR06D00398

It is not exactly the same problem you are encountering, but it indicates how to set the path in the node.cfg.

Let us know the outcome.

Kind regards,

astephan2525 · 02-26-2011, 02:54 AM

Turns out my problem is a bug in fluxbox (I'm trying to use fluxbox and not KDE because it's lighter): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546707
I think the NXLogin::reset error was a red herring. So forget about fluxbox, I'm going to use icewm. Cheers.

astephan2525 · 02-26-2011, 02:55 AM

By the way the clue was that fluxbox was using 100% of the CPU.

Quantumstate · 03-04-2011, 07:36 AM

Not using 100% CPU here.

Yeah, Nomachine's Support has stopped responding to me. I guess my problem is too hard for them.

I have to ditch this PoS.