search

gco / neatx

Automatically exported from code.google.com/p/neatx
0 stars 2 forks source link

old sessions not getting cleared up and preventing new session startup #19

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.Start with an empty sessions directory for the Neatx server.
2.Open a NX session to Neatx server (with virtual desktop enabled; I'm
using XFCE4)
3.Instead of disconnecting or terminating through Neatx dialog, log out via
the window manager. I get an error about having no response from NX server.
4.Try opening a new NX session to the same Neatx server. I get an "Internal
Error"

What is the expected output? What do you see instead?

Based on NoMachine NX server's behavior, I expect logging out through the
window manager to terminate the session and allow me te start a new session
the next time I connect. However, I get an error. Detail (personal details
redacted):

NX> 203 NXSSH running with pid: 30140
NX> 285 Enabling check on switch command
NX> 285 Enabling skip of SSH config files
NX> 285 Setting the preferred NX options
NX> 200 Connected to address: 128.32.xxx.xx on port: 22
NX> 202 Authenticating user: nx
NX> 208 Using auth method: publickey
HELLO NXSERVER - Version 3.3.0 - GPL
NX> 105 Hello nxclient - version 3.3.0
NX> 134 Accepted protocol: 3.3.0
NX> 105 Set SHELL_MODE: SHELL
NX> 105 Set AUTH_MODE: PASSWORD
NX> 105 Login
NX> 101 User: 
NX> 102 Password: **********
NX> 103 Welcome to: xxxx user: byungkyup
NX> 105 Listsession --user="byungkyup" --status="suspended,running"
--geometry="1024x600x24+render" --type="unix-application"
NX> 127 Session list of user 'byungkyup':
Display Type             Session ID                       Options  Depth
Screen         Status      Session Name
------- ---------------- -------------------------------- -------- -----
-------------- ----------- ------------------------------
263     unix-application 7A7F704853EF07C6DEB4BC3957279C6F -RD--PSA    24
1018x556       Running     xxxx

NX> 148 Server capacity: not reached for user: byungkyup
NX> 105 Restoresession  --virtualdesktop="1" --application="xfce4-session"
--link="lan" --backingstore="1" --encryption="1" --cache="16m"
--images="64m" --shmem="1" --shpix="1" --strict="0" --composite="1"
--media="0" --imagecompressionmethod="3" --imagecompressionlevel="-1"
--render="1" --session="xxxx" --type="unix-application"
--geometry="1024x574" --client="linux" --keyboard="pc102/us"
--id="7a7f704853ef07c6deb4bc3957279c6f" --virtualdesktop="1"
NX> 500 Internal error
NX> 999 Bye.
NX> 280 Exiting on signal: 15

What version of the product are you using? On what operating system?

I am using this an Debian Lenny, the version is the one checked out from
the SVN today, July 28th, 2009.

Please provide any additional information below.

In order to be able to connect to the same Neatx server with the same
account after this, I have to go into the server and manually delete the
session directory.

Also, although if I terminate a session through Neatx's dialog, I can
restart a new session later, it doesn't appear that Neatx actually cleans
up the old session directories (unless it does some periodic clean-up).
Also, existence of these old session directories, for some reason, stopped
me from being able to reproduce this result (hence the step 1).

Original issue reported on code.google.com by byungk...@gmail.com on 28 Jul 2009 at 4:43

GoogleCodeExporter commented 9 years ago 
You are correct that it doesn't cleanup old session dirs currently. Can you 
provide
the debug logs from /var/log/user.log for this please? Preferably for both the
original session, and the followup session that fails to start. Thanks

Steve

Original comment by kormat on 28 Jul 2009 at 7:43

GoogleCodeExporter commented 9 years ago 
I am attaching the debug logs asked for. I put 4 newlines between the first
connection (starting with clean session directory) and the second connection 
(after
the logout from first connection ended unsuccessfully).

I also redacted some of the personal information, such as the server name.

Original comment by byungk...@gmail.com on 28 Jul 2009 at 8:35

Attachments:

GoogleCodeExporter commented 9 years ago 
Fantastic, thanks. I see two problems. One is that nxagent is dying 
unexpectedly:

Jul 28 13:24:04 xxxx nxnode[9263]: ERROR daemon:580 /usr/bin/nxagent[9267] 
failed
(status=None, signal=13)

And the other is that the session isn't being fully shutdown (specifically the
session neatx.data file isn't being updated correctly) so the next connection 
tries
to reconnect to it.

Signal 13 is SIGPIPE, meaning nxagent was trying to write to a pipe, but the 
far end
closed.

I don't know why either of these are happening, i'll try and reproduce the 
problem here.

Original comment by kormat on 29 Jul 2009 at 5:57

GoogleCodeExporter commented 9 years ago 
Just for reference, the default sessions dir in my setup are at
'/usr/local/var/lib/neatx/sessions/'

Original comment by plcarva...@gmail.com on 2 Sep 2009 at 6:23

GoogleCodeExporter commented 9 years ago 
for me, session can be terminated because nxagent exits with code 127 (file not 
found - i still have to find out why...), and old session information is not 
cleaned 
up, preventing new sessions from being created. would be nice if old session 
information would be cleaned up properly always.

Original comment by taa...@gmail.com on 7 Sep 2009 at 12:34

GoogleCodeExporter commented 9 years ago 
@taarp: if you can get me the full session logs for when that happens, i might 
have a
chance of hunting down what's going on there. It sounds like the session isn't
correctly marking itself as finished (or possibly isn't noticing that nxagent 
has
exited at all), which will definitely screw things up.

Original comment by kormat on 8 Sep 2009 at 6:01

GoogleCodeExporter commented 9 years ago 
@byungkyup - I've just noticed something, you're using nxclient 3.2.X. Neatx 
doesn't
support any version other than 3.3.X. That could well be the cause of nxagent
crashing like that.

Re: the session not being cleaned up, i did a bunch of work on improving the 
handling
of child processes exiting in daemon.py a while ago, it doesn't look like you 
have
those improvements. So i'd recommend getting an updated copy of the source from 
svn,
and seeing if that helps. If not, the improved logging might give us more of a 
clue why.

Original comment by kormat on 8 Sep 2009 at 6:09

GoogleCodeExporter commented 9 years ago 
I am having exactly the same problem.  There's a "ghost" session that won't die.

When I try to log on, I get the following error:

NX> 203 NXSSH running with pid: 47638
NX> 285 Enabling check on switch command
NX> 285 Enabling skip of SSH config files
NX> 285 Setting the preferred NX options
NX> 200 Connected to address: 128.84.95.130 on port: 22
NX> 202 Authenticating user: nx
NX> 208 Using auth method: publickey
HELLO NXSERVER - Version 3.3.0 - GPL
NX> 105 Hello nxclient - version 3.3.0
NX> 134 Accepted protocol: 3.3.0
NX> 105 Set SHELL_MODE: SHELL
NX> 105 Set AUTH_MODE: PASSWORD
NX> 105 Login
NX> 101 User: 
NX> 102 Password: **********
/tmp/launch-TbX6Xj/: unknown host. (nodename nor servname provided, or not 
known)
NX> 103 Welcome to: megalodon.redrover.cornell.edu user: pgill
NX> 105 Listsession --user="pgill" --status="suspended,running"
--geometry="1440x900x32+render" --type="unix-gnome"
NX> 127 Session list of user 'pgill':
Display Type             Session ID                       Options  Depth Screen 

   Status      Session Name
------- ---------------- -------------------------------- -------- -----
-------------- ----------- ------------------------------
52      unix-gnome       25C5A2FF54B21EAB5603365C963074E9 -RD--PSA    24 
1440x852   
   Suspended   Megalodon

NX> 148 Server capacity: not reached for user: pgill
NX> 105 Restoresession  --link="adsl" --backingstore="1" --encryption="1"
--cache="32m" --images="64m" --shmem="1" --shpix="1" --strict="0" 
--composite="1"
--media="0" --session="megalodon" --type="unix-gnome" --geometry="1440x852"
--client="macosx" --keyboard="query" --id="25c5a2ff54b21eab5603365c963074e9"
NX> 500 Internal error
NX> 999 Bye.
NX> 280 Exiting on signal: 15

The directory /usr/local/var/lib/neatx/sessions/25C5A2FF54B21EAB5603365C963074E9
exists on the server, but when I try to delete this session, I get the 
following:

root@megalodon:/usr/local/var/lib/neatx/sessions# nxserver --force-terminate
25C5A2FF54B21EAB5603365C963074E9
NX> 100 NXSERVER - Version 3.2.0-74-SVN OS (GPL, using backend: 3.3.0)
NX> 500 Error: Session 25C5A2FF54B21EAB5603365C963074E9 could not be found.
NX> 999 Bye

It seems like I'm in a fix where this session exists enough to mess things up, 
but it
doesn't exist enough to be deleted cleanly.

Incidentally, just moving this directory doesn't solve the problem.  On ther 
server,
I tried:

root@megalodon:/usr/local/var/lib/neatx/sessions# mv
./25C5A2FF54B21EAB5603365C963074E9 
25C5A2FF54B21EAB5603365C963074E9_old_and_broken
root@megalodon:/usr/local/var/lib/neatx/sessions# nxserver --cleanup
NX> 100 NXSERVER - Version 3.2.0-74-SVN OS (GPL, using backend: 3.3.0)
NX> 500 Error: No running sessions found.
NX> 999 Bye
root@megalodon:/usr/local/var/lib/neatx/sessions# nxserver --restart
NX> 100 NXSERVER - Version 3.2.0-74-SVN OS (GPL, using backend: 3.3.0)
NX> 123 Service stopped
NX> 122 Service started
NX> 999 Bye
root@megalodon:/usr/local/var/lib/neatx/sessions# 

Then the client gets a slightly different error message:

NX> 203 NXSSH running with pid: 47684
NX> 285 Enabling check on switch command
NX> 285 Enabling skip of SSH config files
NX> 285 Setting the preferred NX options
NX> 200 Connected to address: 128.84.95.130 on port: 22
NX> 202 Authenticating user: nx
NX> 208 Using auth method: publickey
HELLO NXSERVER - Version 3.3.0 - GPL
NX> 105 Hello nxclient - version 3.3.0
NX> 134 Accepted protocol: 3.3.0
NX> 105 Set SHELL_MODE: SHELL
NX> 105 Set AUTH_MODE: PASSWORD
NX> 105 Login
NX> 101 User: 
NX> 102 Password: **********
/tmp/launch-TbX6Xj/: unknown host. (nodename nor servname provided, or not 
known)
NX> 103 Welcome to: megalodon.redrover.cornell.edu user: pgill
NX> 105 Listsession --user="pgill" --status="suspended,running"
--geometry="1440x900x32+render" --type="unix-gnome"
NX> 127 Session list of user 'pgill':
Display Type             Session ID                       Options  Depth Screen 

   Status      Session Name
------- ---------------- -------------------------------- -------- -----
-------------- ----------- ------------------------------
52      unix-gnome       25C5A2FF54B21EAB5603365C963074E9 -RD--PSA    24 
1440x852   
   Suspended   Megalodon

NX> 148 Server capacity: not reached for user: pgill
NX> 105 Restoresession  --link="adsl" --backingstore="1" --encryption="1"
--cache="32m" --images="64m" --shmem="1" --shpix="1" --strict="0" 
--composite="1"
--media="0" --session="megalodon" --type="unix-gnome" --geometry="1440x852"
--client="macosx" --keyboard="query" --id="25c5a2ff54b21eab5603365c963074e9"
NX> 500 Failed to load session
NX> 105 NX> 280 Exiting on signal: 15

If only there were some way to cleanly remove a session.  *sigh*

Original comment by Patrick....@gmail.com on 2 Nov 2009 at 8:00

GoogleCodeExporter commented 9 years ago 
I've discovered a workaround.  Every time you can't log on via neatx, you can 
change
the name of a saved session on the client.  This then gives the client the 
chance to
create a new session.

You still can't remove the old sessions, but at least you can get a remote 
desktop again.

Original comment by Patrick....@gmail.com on 4 Nov 2009 at 6:38

GoogleCodeExporter commented 9 years ago 
@patrick.robert.gill

There's something else going on there. If you run "which nxserver", what does 
it say?
Neatx's nxserver doesn't accept those commands:

root@jaunty:~(1:0)# /usr/local/lib/neatx/nxserver --force-terminate asdasfd
Usage
=====
  nxserver [options]

nxserver: error: no such option: --force-terminate

It also shouldn't be in your path, as it's an internal command. I'm guessing 
you also
have FreeNX installed on your system. As for cleaning up ghost sessions, 
deleting the
contents of the neatx session dir should be enough 
(/usr/local/var/lib/neatx/sessions/).

Original comment by kormat on 1 Dec 2009 at 8:54

GoogleCodeExporter commented 9 years ago 
I do have nxserver in my path; maybe I did try FreeNX at one time.

which nxserver
/usr/bin/nxserver

You're right that cleaning up /usr/local/var/lib/neatx/sessions/ did the trick
removing the ghosts.

Thanks!

Original comment by Patrick....@gmail.com on 1 Dec 2009 at 9:32

GoogleCodeExporter commented 9 years ago 
Hi,
I though to circumvent the logout issue by having my own script being executed
instead of the window manager logout. I wanted to execute nxdialog like that:
nxdialog --dialog yesnosuspend --parent $PID --message "bla" --caption "bla"

The Terminate works nicely but the Disconnect does not. This is because in
HandleSessionAction(agentpid, action) DISCONNECT and TERMINATE act on different 
PIDs.
Would it be possible to use the agentpid also for DISCONNECT. I added a 
possbible
solution.

Greeting,
erazortt

Original comment by erazo...@gmail.com on 16 Feb 2010 at 12:33

Attachments:

GoogleCodeExporter commented 9 years ago 
@erazortt: Good idea. I took a look at the pid handling, and how nxagent calls 
nxdialog, and did a bit of cleanup. Patch out for review. Thanks for spotting 
that.

Original comment by kormat on 19 Feb 2010 at 1:24

GoogleCodeExporter commented 9 years ago 
@erazortt: your issue should be fixed in 
http://code.google.com/p/neatx/source/detail?
r=56

Original comment by kormat on 19 Feb 2010 at 3:41

GoogleCodeExporter commented 9 years ago 
There is no dialog anymore but there is the follwoing error message in 
/var/log/messages:

Feb 19 22:22:33 pcikf26 nxdialog[5468]: ERROR cli:68 Caught exception
Feb 19 22:22:33 pcikf26 nxdialog[5468]: Traceback (most recent call last):
Feb 19 22:22:33 pcikf26 nxdialog[5468]:   File
"/usr/lib/python2.4/site-packages/neatx/cli.py", line 62, in Main
Feb 19 22:22:33 pcikf26 nxdialog[5468]:     self.Run()
Feb 19 22:22:33 pcikf26 nxdialog[5468]:   File
"/usr/lib/python2.4/site-packages/neatx/app/nxdialog.py", line 224, in Run
Feb 19 22:22:33 pcikf26 nxdialog[5468]:     if dlgtype in 
(constants.DLG_TYPE_PULLDOWN,
Feb 19 22:22:33 pcikf26 nxdialog[5468]: AttributeError: 'NxDialogProgram' 
object has
no attribute 'option'

I guess in file nxdialog.py line 225:
constants.DLG_TYPE_YESNOSUSPEND) and not self.option.agentpid:
should be:
constants.DLG_TYPE_YESNOSUSPEND) and not self.options.agentpid:

Greets,
erazortt

Original comment by erazo...@gmail.com on 19 Feb 2010 at 9:30

GoogleCodeExporter commented 9 years ago 
Hi I just found another bug related to this:

Feb 21 01:06:41 pcikf26 nxdialog[18569]: ERROR cli:68 Caught exception
Feb 21 01:06:41 pcikf26 nxdialog[18569]: Traceback (most recent call last):
Feb 21 01:06:41 pcikf26 nxdialog[18569]:   File
"/usr/lib/python2.4/site-packages/neatx/cli.py", line 62, in Main
Feb 21 01:06:41 pcikf26 nxdialog[18569]:     self.Run()
Feb 21 01:06:41 pcikf26 nxdialog[18569]:   File
"/usr/lib/python2.4/site-packages/neatx/app/nxdialog.py", line 254, in Run
Feb 21 01:06:41 pcikf26 nxdialog[18569]:     
ShowYesNoSuspendBox(message_caption,
message_text))
Feb 21 01:06:41 pcikf26 nxdialog[18569]:   File
"/usr/lib/python2.4/site-packages/neatx/app/nxdialog.py", line 166, in
HandleSessionAction
Feb 21 01:06:41 pcikf26 nxdialog[18569]:     logging.info("Disconnecting from
session, sending SIGHUP to %s", ppid)
Feb 21 01:06:41 pcikf26 nxdialog[18569]: NameError: global name 'ppid' is not 
defined

Now I attached a patch for solving both problems.

Original comment by erazo...@gmail.com on 21 Feb 2010 at 12:23

Attachments:

GoogleCodeExporter commented 9 years ago 
Hey, nxdialog was fixed in http://code.google.com/p/neatx/source/detail?r=59 , 
thanks.

Original comment by kormat on 5 Mar 2010 at 12:56

GoogleCodeExporter commented 9 years ago 
heya,

I just wanted to check if this issue was still active, or not? Is it ok to 
Disconnect 
from NeatX?

I ask because I was just getting the "Internal error" message, as well as 
another one 
from another user "The NX service is not available ro the NX access was 
disabled on 
host <ip>".

I've attached my /var/log/user.log

Cheers,
Victor

Original comment by victorh...@gmail.com on 4 May 2010 at 1:41

Attachments:

GoogleCodeExporter commented 9 years ago 
I'm running into this issue with quite some frequency, on multiple systems.  
Deleting 
stale session files fixes it.

Original comment by luke.hutch on 4 May 2010 at 1:43

GoogleCodeExporter commented 9 years ago 
Same issue over here.
Installed neatx on Ubuntu 10.04, did the "reboot" and can not log any more to 
remote PC. Removing 
session from /var/lib/neatx/sessions did the trick. After next reboot the 
problem remained. Client - 
NXClient for Win 3.4.0.7

Advice how to use http://code.google.com/p/neatx/source/detail?r=59 patch.

Original comment by max...@gmail.com on 21 May 2010 at 2:30

GoogleCodeExporter commented 9 years ago 
When "Disconnect"-ed properly, instead of just "sudo reboot", seems that 
session is
closed properly and relogin works well.

Original comment by max...@gmail.com on 21 May 2010 at 2:52

GoogleCodeExporter commented 9 years ago 
I've just started working with NeatX, and spent considerable time on this bug.  
My
rough testing shows that under Ubuntu 10.04 for both client and server OS's 
that the
NoMachine client is likely the culprit.
nxclient_3.4.0-7_i386.deb

Connect to the server first time, launch program (terminal), and 
disconnect/suspend.
 Sometimes the server side shows "suspended" other times it's just "suspending" that
will wait forever.  Client app *appears* to exit normally.  Looking at client 
side ps
& netstat you'll see that nxssh stays connected to the ssh port of there server.

Connect again from the same client computer and if the server didn't get the 
session
switched to "suspended" the connection will timeout since it can't resume.

On the client side now kill the running nxssh apps and you'll notice on the 
server
side that the session now goes to "suspended".  Try connecting with the client 
again
and everything connects fine and resumes the session where left off.

You can repeat this over and over.  Even sessions that terminate or suspend 
properly
are still hanging with nxssh connected to port 22 on the server side.

Original comment by flactem...@gmail.com on 27 May 2010 at 1:55

GoogleCodeExporter commented 9 years ago 
heya,

Just thought I'd point out, I experienced this bug on the Windows NX Client as 
well.

Basically, clicking on Suspend, and it wouldn't reliably Resume the next time 
you 
tried to (had to delete sessions from /var/lib/neatx/sessions.

Cheers,
Victor

Original comment by victorh...@gmail.com on 27 May 2010 at 2:47

GoogleCodeExporter commented 9 years ago 
I wanted to post a followup to my comment above, post 22.  (Want to thank 
Victor, as
it was his post that pointed me at the client side connection hanging open.)

Not sure this is actually a client side issue afterall, but rather a problem 
with the
ssh session disconnect.  It's likely that the neatx isn't sending the proper 
signals
for disconnect to the nxssh client.  Normally I'd diagnose with wireshark, but 
being
ssh that's not going to work.  

I'm testing neatx under a virtualbox Ubuntu 10.04 desktop installation.  
Currently
one virtual machine with NoMachine NXServer Free edition and the other with 
neatx. 
Both servers have ssh set to debug mode so I can see what's happening with the 
ssh
connections.  Both servers are a clone of the same base installation so that 
the only
difference is which flavor of NX server is running.

Looking at server side logs shows nothing unusual or very different from each 
other.
 I've been specifically looking at the data just before and after I use Ubuntu's logout.

NXServer Free Edition:
I can connect and disconnect from the client side cleanly everytime.  There's 
never a
hanging nxssh process on the client side when disconnecting from the NXServer 
free
edition.

neatx:
On the server side I see that once I request a disconnect from the service 
there is
rarely a disconnect from the ssh service.  Client side nxssh process just sits 
there
forever, and I've given it up to 1 hour to die.  If I kill the process on the 
client
side then the server side logs show the disconnect, and then the connection is
cleaned up and the session close is processed correctly it seems.

Unfortunately the nxclient doesn't seem to have a debug option, so it's hard to 
see
what is going on with that side.  The limited logs that are available for the 
client
sessions seem to be nearly identical other than the notice of a terminated nxssh
after waiting 2 minutes post screen logout.  Actually those client side logs 
don't
generally log anything about the connection closing.

If there are other troubleshooting methods to watch what's going I'd be wiling 
to
give it a try.

Original comment by flactem...@gmail.com on 27 May 2010 at 5:58

GoogleCodeExporter commented 9 years ago 
To sniff nxssh session you need to become a man-in-the-middle. The last time I 
did it 
was 10 years ago, so modern instruments should do it more easily. However, I 
could not 
find a Wireshark solution, but Ettercap seems to be just what you need 
http://ettercap.sourceforge.net/ dniff also claims to be capable of doing this 
thing. 
http://www.monkey.org/~dugsong/dsniff/

Original comment by techtonik@gmail.com on 27 May 2010 at 6:20

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
You can record the SSH conversation by replacing the nx users' shell with a 
program
that logs all input/output and executes the login program behind it. Socat 
(invoked
in a shell script) can be used for this.

Original comment by han...@google.com on 27 May 2010 at 10:49

GoogleCodeExporter commented 9 years ago 
I've got the same issue here.

I'm not sure it's a neatx problem as I've been unable to restore any session 
with both freeNX and neatX since upgrading to Ubuntu 10.04.

Using neatX I have the same error as reported in this thread. Cleaning the 
/var/lib/neatx/sessions directory solves the problem about creating a new 
session though.

My client is the nomachine windows client 3.4.0-7.

Original comment by florent....@gmail.com on 22 Jun 2010 at 7:45

GoogleCodeExporter commented 9 years ago 
Even if it's the client that is leaving around old stale sessions, shouldn't 
neatx automatically clean them up rather than bailing?  There must be a way to 
test if sessions are still live or not.  Does anybody know what is actually 
wrong with the stale sessions?

Original comment by luke.hutch on 22 Jun 2010 at 12:54

GoogleCodeExporter commented 9 years ago 
heya,

Just experienced it again when one of my users couldn't log in.

Yeah, I have to agree with Luke, surely there's an alternative to just aborting 
like this?

Cheers,
Victor

Original comment by victorh...@gmail.com on 25 Jun 2010 at 1:22

GoogleCodeExporter commented 9 years ago 
Right, if it tries to start up an old session and the session is stale, 
shouldn't it just start a new session?  Does anybody know exactly where the 
failure is occuring?

Original comment by luke.hutch on 25 Jun 2010 at 3:09

GoogleCodeExporter commented 9 years ago 
I have the same problem on a clean install of Ubuntu 10.04 64bit.

Original comment by smith.ti...@gmail.com on 29 Jun 2010 at 6:09

GoogleCodeExporter commented 9 years ago 
I have found a workaround for those using windows clients connecting to ubuntu 
10.04 machines.  If you "disconnect" the session instead of "terminating" it, 
it will not create a new session the next time you connect to the machine 
thereby mitigating the failure mode experienced here that is only remedied by 
deleting the contents of the session folder.

Original comment by Jcalai...@gmail.com on 30 Jun 2010 at 6:23

GoogleCodeExporter commented 9 years ago 
Hi guis, I have found a workaround.
in my neatx.con:
-----------------
xsession-path = /path/to/my/startgnomesession

startgnomesession:
--------------------
#Execute gnome session. This command exits only when user terminates the 
session.
/usr/bin/dbus-launch --exit-with-session /usr/bin/gnome-session

# waiting for gnome exit
sleep 1

# NX_ROOT is the path to user session file.
# delete it after 10 seconds 
if [ "${NX_ROOT}" != "" ]; then
  sleep 10 && rm -rf "${NX_ROOT}" >/dev/null 2>&1 &
fi

Neatx is a great project!

Original comment by deadcrac...@yahoo.it on 27 Jul 2010 at 4:06

GoogleCodeExporter commented 9 years ago 
Hello, 
I experience the same problem on Kubuntu 10.04 x86_64. Often deleting 
/var/lib/neatx/session/* (remote) and (local) ~/.nx/S-* helps. But this time it 
didn't.
One major drawback of this workaround is that resuming a session never works 
and this is one of the main features that are great with NX.

I dumped some of the session information from the remote-host here. Hope this 
helps debugging the problem and is not against any policy here.

Thanks
Chris

tux:/var/lib/neatx/sessions/5BF57C43FB3B48DCD06251DA7524185E>ls
C-tux.ded.mentorg.com-231-5BF57C43FB3B48DCD06251DA7524185E  neatx.data
authority                                                   nxnode.sock
cache-kde                                                   options
tux:/var/lib/neatx/sessions/5BF57C43FB3B48DCD06251DA7524185E>cat options
nx/nx,fullscreen=0,product=Neatx-GPL,shpix=1,clipboard=both,render=1,composite=1

,cache=16M,geometry=1440x851,accept=127.0.0.1,client=linux,strict=0,cleanup=0,co

okie=46E985F4F67E0E95F2664D381C38A500,resize=0,keyboard=pc105/de,images=64M,link

=wan,type=kde,id=tux.ded.mentorg.com-231-5BF57C43FB3B48DCD06251DA7524185E,backin

gstore=1,shmem=1:231
tux:/var/lib/neatx/sessions/5BF57C43FB3B48DCD06251DA7524185E>ls
C-tux.ded.mentorg.com-231-5BF57C43FB3B48DCD06251DA7524185E  neatx.data
authority                                                   nxnode.sock
cache-kde                                                   options
tux:/var/lib/neatx/sessions/5BF57C43FB3B48DCD06251DA7524185E>ls
C-tux.ded.mentorg.com-231-5BF57C43FB3B48DCD06251DA7524185E  authority  
cache-kde  neatx.data  nxnode.sock  options
tux:/var/lib/neatx/sessions/5BF57C43FB3B48DCD06251DA7524185E>find .
.
./neatx.data
./C-tux.ded.mentorg.com-231-5BF57C43FB3B48DCD06251DA7524185E
./C-tux.ded.mentorg.com-231-5BF57C43FB3B48DCD06251DA7524185E/errors
./C-tux.ded.mentorg.com-231-5BF57C43FB3B48DCD06251DA7524185E/stats
./options
./nxnode.sock
./authority
./cache-kde

tux:/var/lib/neatx/sessions/5BF57C43FB3B48DCD06251DA7524185E>cat 
./C-tux.ded.mentorg.com-231-5BF57C43FB3B48DCD06251DA7524185E/errors
Loop: WARNING! Signals were not blocked in process with pid '13154'.

tux:/var/lib/neatx/sessions/5BF57C43FB3B48DCD06251DA7524185E>cat 
./C-tux.ded.mentorg.com-231-5BF57C43FB3B48DCD06251DA7524185E/stats
tux:/var/lib/neatx/sessions/5BF57C43FB3B48DCD06251DA7524185E>cat ./neatx.data
{
  "username": "cparg",
  "fullscreen": false,
  "rootless": false,
  "name": "Tux",
  "virtualdesktop": true,
  "geometry": "1440x851",
  "hostname": "tux.ded.mentorg.com",
  "state": "terminated",
  "id": "5BF57C43FB3B48DCD06251DA7524185E",
  "port": 4231,
  "ssl": true,
  "screeninfo": "1440x851x24+render",
  "options": null,
  "cookie": "46E985F4F67E0E95F2664D381C38A500",
  "_updated": 1285698871.481848,
  "type": "unix-kde",
  "display": 231,
  "subscription": "GPL"
}
tux:/var/lib/neatx/sessions/5BF57C43FB3B48DCD06251DA7524185E>cat options
nx/nx,fullscreen=0,product=Neatx-GPL,shpix=1,clipboard=both,render=1,composite=1
,cache=16M,geometry=1440x851,accept=127.0.0.1,client=linux,strict=0,cleanup=0,co
okie=46E985F4F67E0E95F2664D381C38A500,resize=0,keyboard=pc105/de,images=64M,link
=wan,type=kde,id=tux.ded.mentorg.com-231-5BF57C43FB3B48DCD06251DA7524185E,backin
gstore=1,shmem=1:231

Original comment by cp...@gmx.de on 28 Sep 2010 at 6:46

GoogleCodeExporter commented 9 years ago 
I'm a big fan of Neatx on Ubuntu 10.04 x86. Normally I can reconnect to my 
sessions if the are cleanly disconnected. However every once in a while a 
session will have a problem with the client timeout before the connection can 
be established. I'm not sure if there are debug logs I could look at on the 
server? I have to do the server session cleanup to get things moving again.

Original comment by martin.m...@gmail.com on 29 Sep 2010 at 9:19

GoogleCodeExporter commented 9 years ago 
Had a weird breakthrough with this: if sessions are "dead", sometimes they can 
be opened from one machine but not another.  For example, on client A, I open a 
connection to server S, then later disconnect, go home, and re-connect to 
server S from client B (reconnecting to the same disconnected session).  I 
leave this connection running all night long.  For some reason the NXClient 
software crashes and when I wake up in the morning the window is gone.  I try 
to reconnect to server S from client B, and it times out.  I thought it was 
time to do the usual "ssh to server S then rm -rf /var/lib/neatx/session/*".  
However instead I went back to work and tried reconnecting from client A, and 
it reconnects fine.  It is the *same* session in all cases, but somehow the 
combination of some staleness in /var/lib/neatx/session on the server and some 
brokenness on crashed client A seems to disallow reconnecting to the session, 
whereas client B can still reconnect.

Original comment by luke.hutch on 26 Oct 2010 at 8:48

GoogleCodeExporter commented 9 years ago 
The attached script seemed to solve this issue for me. I simply run it at then 
close of every session. Works great!

Original comment by mmd...@gmail.com on 29 Oct 2010 at 7:48

Attachments:

GoogleCodeExporter commented 9 years ago 
mmdj4u: yes, but as I mentioned in Comment 37, the stale sessions are not 
always dead (sometimes they can be reached from one machine but not another).  
Removing the session directories kills them.  Sometimes you really need to 
re-connect to an existing non-dead-but-somehow-stale session, not just kill 
it...

Also it's a shame that this is even a problem.  Is anyone at Google still 
working on neatx?

Original comment by luke.hutch on 29 Oct 2010 at 8:52

GoogleCodeExporter commented 9 years ago 
I second the last comment.  I need to be able to reliably connect back to a 
session that was previously started, not just blow it away.  

I wish this were fixed, because I find that neatx is much more CPU friendly 
than nomachine's NX.  (When I'm disconnected, from NX I have 15% cpu usage by 
NX_agent, when I use neatx, I don't have any CPU usage that registers more than 
0 when I'm disconnected, though the processes in the disconnected session are 
using CPU.)  I'm running a CPU intensive task on neatx and NX doesn't cut it 
for me.

Rob

Rob

Original comment by kl7na.pskmail@gmail.com on 24 Dec 2010 at 2:58

GoogleCodeExporter commented 9 years ago 
I have found that sometimes you can reattach to the same "defunct" session from 
the same computer.  I'm trying to discover what the trick is.  At this point 
what I think I did that might have been relevant is to disconnect my VPN and 
use another one or maybe the same one.  I also tried using QTNX instead of the 
nomachine client (unsuccessfully).

Rob

Original comment by kl7na.pskmail@gmail.com on 24 Dec 2010 at 11:31

GoogleCodeExporter commented 9 years ago 
Further testing indicates if I just disconnect the VPN and then reconnect it 
(same VPN), I can then reconnect to the "defunct" session.

Original comment by kl7na.pskmail@gmail.com on 24 Dec 2010 at 1:36

GoogleCodeExporter commented 9 years ago 
I don't know if this is related, but sometimes when I am not using a VPN, and 
cannot reconnect, it claims it has timed out.  When I suspend the machine I was 
trying to use to connect to it, upon wake up, I get a message saying that my 
connection was severed, and now I am disconnected, which is strange because I 
wasn't able to reconnect.

Original comment by kl7na.pskmail@gmail.com on 6 Jan 2011 at 3:18