[FreeNX-kNX] Bug: negotiating link parameters -> timeout ON resume session. v.0.6.0/2.1.0-17

[torrr com]

Hi,

1. When I connect to a suspended session, negotiating parameter link
appears, and stay even after I am connected. After about a minute or so, the
session disappear, and the negotiating parameter link window, becomes a
connection timeout window.



2. Some sessions that were opened from a computer at an other place don't
give a resume option. The resume button is disabled and only the other
buttons are available. When returning to the other place the same suspended
sessions does give a resume option.


I did some experiments below, and

here is __THE CONCLUSION__ (of the experiments for problem 1):



When connecting via nxclient for windows v.2.1.0-17 the nxclient start two
nxssh.exe processes. The first is the main one, and the second is a
temporary one which disappears later on. The first nxssh.exe process behaves
differently when it connects to a new session, and when it resumes a
suspended session. To sum it all up, nxssh.exe doesn't exit on the first
suspend on the sesssion, and thus it blocks subsequent resumes, and cause
the connection timeout. On the other hand if it is not the first suspend on
the session nxssh.exe exit nicely. It also exit nicely on logout. In more
words, when nxssh.exe starts due to a new session, then after suspending the
session, and after the whole application appears, and seems to have exited,
the main nxssh.exe doesn't exit and keeps running in the background. If a
logout is performed instead of a suspend the nxssh.exe exit nicely. When
trying to resume a suspended session, with the previous nxssh.exe process
still running in the background, the session fails with a connection
timeout, after it appears to be running for a minute or so. Once the main
nxssh.exe is manually terminated, resuming the suspended session succeeds.
Following suspend and resume also succeed, and watching the
nxssh.exeprocess shows that on a resumed session, it does exit nicely
once the
session is re-suspended.



Remaining questions:



1. What should I do, so that ignorant users will be able to suspend/resume?

2. Why does the main nxssh.exe keeps running like it does? (Because if the
server is still connected to it, and keeps it running, then the server may
be adapted to sever the connection, or to instruct nxssh.exe to exit after a
suspend.)

3. nxclient.exe also doesn't exit nicely and keeps running in the
background. After the experiments below I have no session running and 5
nxclient.exe processes runing which take up RAM, and maybe also have a part
in this bug.

4. The first #2 above.







Experiment:

------------

I started having these problems now, and I don't know why. Before I did do
suspend and resume and it all was fine. Here is something from the
~/.nx/C-*/errors:

--------------------------------------------------------------------
NXTransDialog: WARNING! Couldn't start '/usr/NX/bin/nxclient'. Error is 2
'No such file or directory'.
NXTransDialog: WARNING! Trying with path '/usr/NX/bin:/opt/NX/bin:/usr
/local/NX/bin:/usr/lib/nx:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games'.

Loop: WARNING! Signals were already blocked in process with pid '10742'.
Proxy: WARNING! Handling data for finishing FD#7 channel ID#1.
Proxy: WARNING! Handling data for finishing FD#7 channel ID#1.
Proxy: WARNING! Handling data for finishing FD#7 channel ID#1.
Proxy: WARNING! Handling data for finishing FD#7 channel ID#1.
Proxy: WARNING! Handling data for finishing FD#7 channel ID#1.
----------------------------------------------------------------------



I tried to install the nxclient from nomachine on the freenx machine, due to
the first 4 lines, but it didn't do any good. I tried to see the
/var/log/nxserver.log which I set in /etc/nxserver/node.conf with
NX_LOGLEVEL=7, but that log file was empty. I tried to NX_LOGLEVEL=4, but
the log file was still empty.



I remembered seeing something in the windows local .nx errors file, so I
tried to do it again from a third location. So I
connected-suspended-resumed, and it worked fine, and the errors file was
empty. I suspended-resumed again, and got the problem again. I tried to see
the errors file but it was locked. I opened the task manager and found some
nx* processes, and killed them, and the errors file disappeared. I tried
again to resume and it worked. suspend-resume again and again and again and
it always worked now from this third location. I tried again with an other
user name suspend-resume and failed, again again and again and failed,
looked for that error file I saw before and found a winlog file that ends
with:

---------------------------------------------------------
Couldn't load XKB keymap, falling back to pre-XKB keymap
winBlockHandler - Releasing pmServerStarted
winBlockHandler - pthread_mutex_unlock () returned
Dispatch: Exiting from the dispatcher with exception [2]
----------------------------------------------------------

by the way this connections attempts to the second user were performed while
the first user session was open.


I looked again at the task manager in order to see the nx* processes. I
found there that there were nxesd.exe nxssh.exe again nxssh.exe and
NXWin.exe. I figured maybe if I kill a process here it will help like the
last time. So I figured one of the nxssh.exe is redundant. I watched the cpu
usage, saw one that had usage, and ended the other one. tried again to
resume, and it worked fine. Did suspend-resume again... and it worked fine,
and again ... and fine. And I watch the nxssh.exe and it is like this, when
I start the second session I have a total of 3 nxssh.exe running, after some
time one of the nxssh.exe disappear by itself, and I am left with two
nxssh.exe processes. Once I suspend after a short time one
nxssh.exedisappear and I am left with one. Suspending the session that
is left and
only nx* process left is nxesd.exe .... Why does the problem not happen
again? maybe if I kill nxesd.exe... no. Maybe if I log out from the
suspended resumed session, log back in suspend the first suspend for this
session and resume ... Yes, the problem returned, at the taskmanager this
produced a total of 4 nxssh.exe's. When the timeout occurred I was left with
two persistant nxssh.exe's "serving" one session. I found the idle nxssh.exe,
and ended it. Tried to resume again and the stubborn session resumed fine. 3
nxssh.exe's from which one ended by itself leaving a total of 2 nxssh.exe's.
Loged off from both sessions and re-opened the first. 2 nxssh.exe's are and
one exited leaving 1 nxssh.exe. Suspending. Looking at the nxssh.exe and
waiting for it to disappear. Waited two minutes and it didn't disappear.
Trying to resume. Problem again. Resuming again, in the short time until the
timeout I log out, and watch. All nxssh.exe exit on their own. Now I notice
there are 4 nxclient.exe processes even not a single session is at sight. I
start a new session and watch PIDs: First nxssh.exe is also the one that is
active during the session. The second nxssh.exe appears at a late stage of
connecting, and disappear by itself.



Conclusion:

When connecting via nxclient for windows 2.1.0-17 the nxclient start two
nxssh.exe processes. The first is the main one, and the second is a
temporary one which disappears later on. The second one appear not important
for this problem. The main nxssh.exe process behaves differently when it
connects to a new session, and when it resumes a suspended session. When it
starts a new session after suspending the session and after the whole
application appears to have exited, it doesn't exit and keeps running in the
background. On the other hand if a logout is performed instead of a suspend
it does exit nicely. When trying to resume a suspended session, the same
procedure happens again, but this time if the previous nxssh.exe process is
still running the session fails with a connection timeout, after it appears
to be running for a minute or so. Once the first nxssh.exe is manually
terminated, resuming the suspended session succeeds. Following suspend and
resume also succeed, and watching the nxssh.exe process shows that on a
resumed session, it does exit nicely once the session is re-suspended.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/freenx-knx/attachments/20070420/11f2df3d/attachment.html>