noVNC client logged out after 3 mins

[kishshen]

We use noVNC/Websockify to login to and use a CentOS 6 Linux machine (running TigerVNC server). When the CentOS TigerVNC package was updated around May this year, the noVNC lwindow seem to get killed 3 mins after logging in (the user is sent back to the login page). We rolled back to the older TigerVNC, and the problem did not occur.

We assumed this was an issue with TigerVNC, However, looking at the code changes, it was difficult to see how. However, I just found a bug report that stated:

In that latest release of tigervnc-server (1.1.0-18.el6.x86_64) the default X option now seems to be >'-nolisten TCP' (ie it does not listen on the normal X11 port). The previous versions defaulted to >'-listen TCP' (eg. version 1.1.0-16). I'm not sure if this is intentional or not.

and the -18 version with the -nolisten option is what is giving us the problem.

I understand that Websockify does listen to TCP ports, so can this be the cause of the problem we see? The 3 mins it takes for the noVNC session to be killed seems quite precise, and I suspect it is caused by some timer.

Thanks in advance for any information!

[henickr]

you need to check your websockify log to find out why it is being terminated. there are several reasons why this could happen due to the nature of the connection. there are client side, server side and actual websockify platform issues that each could be the cause of a connection issue.

ssl can cause issues depending on how it is implemented as well.

when you run websockify on centos add a --log-file=/tmp/websockify.log to the command then hit your service and see what happens in there during the disconnect. if there is nothing, fall back to your httpd_error log and also use your access log to confirm that the request even made it to the proxy. (use the command usage if you need help configuring the log file)

Hope this helps.

[kishshen]

Thank you for your help. We tested with CentOS 7 as many of the software packages for CentOS 6 are rather old, and the problem is not there.
As you suggest, the problem is probably very difficult to pin down because there are so many pieces of software involved, so hopefully we don't need to track this problem down now.

On Tuesday, 27 September 2016, 13:24, henickr <[email protected]> wrote:

you need to check your websockify log to find out why it is being terminated. there are several reasons why this could happen due to the nature of the connection. there are client side, server side and actual websockify platform issues that each could be the cause of a problem.ssl can cause issues depending on how it is implemented as well.when you run websockify on centos add a --log-file=/tmp/websockify.log to the command then hit your service and see what happens in there during the disconnect. if there is nothing, fall back to your httpd_error log and also use your access log to confirm that the request even made it to the proxy. Hope this helps.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[DirectXMan12]

cc @samhed -- you're familiar with with TigerVNC, right?

[samhed]

Yes, I'll take a look at this next week!

[DirectXMan12]

Thanks!

[samhed]

I'm investigating more urgent errors with noVNC at the moment, will take a look at this once I have time.