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

[Fabian Franz]

> 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.

Okay.

Now I can see at the end that nxssh did see that the session was closed and still its running? That makes no sense to me, but okay.

> Session: Session terminated at 'Thu Feb 15 13:09:44 2007'.

So to be sure:

Ther is a nxssh process still running _and_ in that same session log there is a Session terminated?

> 
> 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.

Okay.

> > 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.

Okay.

> 
> 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.

Okay.

> 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.

Yes, that might be.

Okay, I need more info:

Do:

- Setup the scenario with hanging nxssh
- Again confirm that in session log there is already a "session terminated" written
- Get output from server:

ptree -p -u user 

and

pstree -p -u nx # best if no other session runs on it at that moment

Can it be that there is a netcat process still hanging around?

Then it might be a problem of netcat not closing the connection directly, when it encounters socket close on remote end.

Last idea I have for the moment.

cu

Fabian