[prev in list] [next in list] [prev in thread] [next in thread]
List: freenx-knx
Subject: [FreeNX-kNX] Bug: negotiating link parameters -> timeout ON resume
From: "torrr com" <torrr.com () gmail ! com>
Date: 2007-04-20 9:58:11
Message-ID: 15e78e5b0704200258y45aa1c1fsfc5e5bd4fe688413 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
[Attachment #5 (text/html)]
Hi,<br><br>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. <br><br><br><br>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. <br><br><br>I did some experiments below, and \
<br><br>here is __THE CONCLUSION__ (of the experiments for problem \
1):<br><br><br><br>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.exe process shows that on a \
resumed session, it does exit nicely once the session is re-suspended. \
<br><br><br><br>Remaining questions:<br><br><br><br>1. What should I do, so that \
ignorant users will be able to suspend/resume?<br><br>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.)<br><br>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. <br><br>4. The first #2 \
above.<br><br><br><br><br><br><br><br>Experiment:<br><br>------------<br><br>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: \
<br><br>--------------------------------------------------------------------<br>NXTransDialog: \
WARNING! Couldn't start '/usr/NX/bin/nxclient'. Error is 2 'No such \
file or directory'.<br>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'. \
<br>Loop: WARNING! Signals were already blocked in process with pid \
'10742'.<br>Proxy: WARNING! Handling data for finishing FD#7 channel ID#1. \
<br>Proxy: WARNING! Handling data for finishing FD#7 channel \
ID#1.<br>
Proxy: WARNING! Handling data for finishing FD#7 channel ID#1. <br>Proxy: WARNING! \
Handling data for finishing FD#7 channel ID#1.<br>Proxy: WARNING! Handling data for \
finishing FD#7 channel ID#1. \
<br>---------------------------------------------------------------------- \
<br><br><br><br> 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. \
<br><br><br><br>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: \
<br><br>---------------------------------------------------------<br>Couldn't \
load XKB keymap, falling back to pre-XKB keymap<br>winBlockHandler - Releasing \
pmServerStarted<br>winBlockHandler - pthread_mutex_unlock () returned <br>Dispatch: \
Exiting from the dispatcher with exception \
[2]<br>----------------------------------------------------------<br><br>by the way \
this connections attempts to the second user were performed while the first user \
session was open. <br><br><br>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.exe disappear 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. \
<br><br><br><br>Conclusion:<br><br>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.<br><br><br><br>
________________________________________________________________
Were you helped on this list with your FreeNX problem?
Then please write up the solution in the FreeNX Wiki/FAQ:
http://openfacts.berlios.de/index-en.phtml?title=FreeNX_FAQ
Don't forget to check the NX Knowledge Base:
http://www.nomachine.com/kb/
________________________________________________________________
FreeNX-kNX mailing list --- FreeNX-kNX@kde.org
https://mail.kde.org/mailman/listinfo/freenx-knx
________________________________________________________________
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic