[FreeNX-kNX] Intended suspend isn't properly resumable

[Durk Strooisma]

>> So, concluding; if I hit the close button and choose "suspend" on the
>> NX client running an NX session, I cannot resume the session properly.
>> The resumed session works for a minute, while another NX client window
>> is showing "Negotiating link parameters". After that minute the NX
>> session window is killed and the other window is showing a time-out.
>
> I _could_ reproduce this once.
>
> But afterwards nxssh was always faster closed down, than I could resume
> the session ...
>
>>
>> BUT, if I kill all processes of a running NX session on the
>> client-side (NXWin, nxssh, etc.) it'll resume perfectly afterwards!
>
> Does it also work for waiting like 10 secs up to a minute or so?

That works as well. What I did:
1. Opened up an NX session with NX Client for Windows 2.1.0-16
2. After a while (like 20 minutes) I killed NXwin.exe, nxssh.exe
   and cygserver.exe using Task Manager.
3. After more than a minute "nxserver --history" shows on the server:
   1004    durk    -       6F02ECD59F2B744BB8A2FE453D7EBB00
2007-02-15 11:24:23     Suspended
4. Opened up an NX session to same server, after 10 minutes.
5. NX Client automatically resumed my killed session.
6. Everything's fine, no other NX Client windows in the background,
   my session is back in the state just before I killed the client
   and remains for at least 5 minutes.

Doing every step as quick as possible also works.

Using the close button to suspend an NX session gives me the behaviour as
stated before; doing every step quickly or very slowly doesn't matter here
as well. BUT nxssh.exe was still in the proces list and I don't know how
long to wait before it disappears... So I killed it and started up the
session again; RESUMING WORKED! So my problem with resuming of sessions is
definitely related to the nxssh.exe proces still being alive.

And now it's getting even more curious... Although there's still the
nxssh.exe being alive, resuming with NX Client for Windows version 1.5.0-138
is NO problem. During a session there are 3 nxssh.exe processes active (two
new, one old), but the older NX client doesn't care. After a logout or
suspend it takes a couple of seconds (like 10), but ALL three nxssh.exe
processes disappear.

Although it isn't neat that a nxssh.exe doesn't disappear, there's something
with NX Client 2.10-16 that makes it troublesome.

> I found that it occured only if I immediately resumed the session after
> starting it.
>
> And if thats the case, it might be a client bug.
>
> You might want to try it also with 2x client, where we have the source
> code for.

I don't know exactly what kind of NX client you're referring to. I've tested
the above steps with the commercial NX Client for Windows version 1.5.0-138
and 2.1.0-16.

> You might also try if it occurs with testdrive servers ...

I did and everything functions as you would expect. In perspective of the
previous observation it's explainable, 'cause I noticed that the local
nxssh.exe processes almost immediately disappear after suspending a session
on the testdrive servers.

For some reason nxssh.exe processes don't disappear (at least for 10
minutes) after suspension when having been connected to a FreeNX server.
With the commercial NX server they do (quickly) afterwards.

I investigated a little more with NX Client for Windows 2.1.0-16:

A running NX session consists of some a cygserver.exe, a NXwin.exe and two
nxssh.exe (local) processes. These two nxssh.exe processes are interesting.
In some cases only ONE nxssh.exe is active! The NX session just behaves as
expected, but in this case the nxssh.exe will NEVER disappear after
suspending that session! BUT when there are TWO nxssh.exe processes while
running an NX session, which is always the case with the testdrive servers,
BOTH processes DO (mostly) disappear after suspension! Though the second one
a little bit slower than the first one, but at least within a couple of
seconds (like 10 secs). Though the nxssh.exe processes disappear a lot
quicker (almost immediately) when having been connected to the testdrive
servers. And like noticed before, when both nxssh.exe disappear, there's no
problem resuming the suspended session.

So it's kinda complicated... I think it's not only a client-related problem.
The difference in behaviour between the testdrive servers and my FreeNX
server makes me think that there's an issue in FreeNX as well.

> If nxssh does not die, I would be itnerested of output of session log,
> i.e. C:\Documents and Settings\<User>/.nx/S-<server>/session.

Here you go:

Info: Display running with pid '1368' and handler '0x110346'.
NXPROXY - Version 2.1.0

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

Info: Proxy running in client mode with pid '4060'.
Session: Starting session at 'Thu Feb 15 13:09:23 2007'.
Info: Synchronizing local and remote caches.
Info: Handshaking with remote proxy completed.
Info: Using adsl link parameters 512/24/1/0.
Info: Using cache parameters 4/4194304/8192KB/8192KB.
Info: Using image streaming parameters 50/128/1024KB/2048/256.
Info: Using image cache parameters 1/1/32768KB.
Info: Using pack method 'no-pack' with session 'unix-kde'.
Info: Using ZLIB data compression 3/3/0.
Info: Using ZLIB stream compression 6/6.
Info: Using cache file
'C:\DOCUME~1\durk\NX73F8~1/cache-unix-kde/S-BB92206732CCE055A0BB107382B644A6'.Info: Listening for font server connections on port '11004'.
Session: Session started at 'Thu Feb 15 13:09:24 2007'.
Info: Established X server connection.
Info: Using shared memory parameters 1/2048K.
Session: Terminating session at 'Thu Feb 15 13:09:44 2007'.
Info: End of NX transport requested by remote.
Info: Shutting down the NX transport.
Session: Session terminated at 'Thu Feb 15 13:09:44 2007'.


Hope this message makes any sense... ;-)

Durk