Waiting for information

Performance issues on linux and mac

TecnetScott 5 years ago updated by Ben Burner 5 years ago 7

Access sessions that are left up for more than 3 or so days on a Linux or Mac machine are unbearably slow when in the session. Mouse/keyboard clicks take several seconds and screen refresh rates go down to once every few seconds. WIndows machines on the same site have no issues whatsoever. Rebooting the machine does not fix this.

ConnectWise Control Version:
Server Affected:
Host Client Affected:
Guest Client Affected:

Good afternoon,

What version of ScreenConnect are you using and are you self- or cloud-hosted? If self-hosted, in what environment have you installed the ScreenConnect server?

When you say "Access sessions that are left up", do you mean a host has been connected to the session for 3+ days, or that the Linux/Mac guest has been connected for at least 3 days? Are you connecting to the Linux/Mac guests via the .NET (Windows) client or the Java client? Also, on what flavor(s) of Linux/OS X have you noticed this behavior?



Waiting for information

This is self-hosted on a 50 mbps full duplex connection.

This is installed on a windows 7 Ent 32bit VM.

ScreenConnect 6.0.11299.6071

If the agent has been installed on the machine for more than 3 days the issue happens (it does not seem to matter if the machine has been rebooted, therefore resetting the connection).

We only connect when needed so we are not leaving settings open.

I am using the .NET installed app.

I have noticed this on Linux Mint, Ubuntu and Mac OSX.

Thank you for clarifying the behavior.

My first suggestion would be to upgrade your ScreenConnect server version to the latest stable build, 6.0.11622 and verify that the Java clients on the Mint, Ubuntu, and OS X machines are also on 6.0.11622.

Since we haven't been able to reproduce this behavior in our test environment, it may be best to submit a support ticket in order for one of our techs to connect to your environment and troubleshoot on one of the affected machines.

It would be helpful if you could also include the output from running the following command on one of the affected Linux machines (substituting in your server's public key thumbprint for the x's):

tail -500 /var/log/screenconnect-xxxxxxxxxxxxxxxx

Also, what version of Java is installed on the Linux machines (use the command "java -version")? We've found that, at this time, the ScreenConnect Java client works best on Linux with OpenJDK 7u121.

Finally, what's the resource consumption like when your Linux endpoints enters the slow state? You can get an summary of resource consumption using the command "top -o %CPU" to display resource use by process sorted by CPU consumption (we're interested in the java processes).



Hi Ben,

Since we usually lose some clients when we update we are waiting until 6.1.x to do that.

If at that point the clients are still having problems I will continue the rest of the steps.



Waiting for information