Subject: Bug#302: Possible solution to #302 ?

From: GZNG Tech <[email-masked]>
Date: Thu, 12 Jun 2014 18:58:17 +0200

Control: tag -1 patch

Hi,

Putting the attached file into your "extensions/post-suspend.d" folder
on the server...
may solve #302 issues...

On Ubuntu that would be an executable named "302_bug-fix" with the
following full path:
/usr/lib/x2go/extensions/post-suspend.d/302_bug-fix
(On other distros just simply locate your "post-suspend.d" folder and
put it there..
PS! Make sure its executable! (chmod 755).

Its may be good to clean up all old sessions before you
start a brand new and fresh session to test this fix.

We were able to reliably reproduce fault/non-fault conditions and after
applying this fix, we're seeing 100% success rates for session resume
with pyhoca....

The source of the issue seem to be that the NX port reappears on the
server within seconds of session suspension.... in  a state where where
its not ready for new incoming connections... (quite frankly it should
not be available at all at this time, should it?)  So either we're
reconnecting to this "faulty" port
or the fresh port fails to open due to the "old port" being in the
way....  Either way NX fails to resume...

The problem seem to be consistently occurring when rapidly
suspending/resuming with pyhoca and if x2goclient experience
abnormal/unclean disconnects that results in suspension.

Either way this little perl script will clean up those stray NX ports by
simply locating and connecting to them... (after which, the port closes,
as it should.)

If this indeed solves the #302 bug, this should probably move from
extensions to being part of the suspend scripts....  but for cleanliness
and admin-friendliness its easier to test it as an extension....

Let us know if this works for you!

(btw: If the supportive subs are adopted to Utils.pm  the script it self
would become quite compact)

Best Regards,
-GZNGET