No I did not find a solution to this. I was more or less told that the 32-bit version of Mono (part of screenconnect) was unpredictable and that upgrading to 64-bit OS was recommended. That said I have not had an 'out of memory' issue for quite a while now. You can try and reinstall screenconnect as that might help. Also, from what I have read, screenconnect seems to be fairly stable in a Windows environment if you have access to that. I have not tried, so I can't say.
As I mentioned previously: after running out of memory repeatedly (about a month ago), I've reinstalled ScreenConnect - but it wasn't until weeks later I've come into this problem once again. If you cannot reproduce the issues on your own virtual machine, then how about SSH'ing into my system to have a look around? This does not seem to be an unreasonable request.
I have had this memory leak issue for at least 4-6 months now. Upgrading to CentOS 64bit to fix this problem doesn't seem like a legitimate answer since (a) that would require reconfiguring my entire server which took weeks to set up; (b) your support page says Linux 32 bit is supported, and (c) there is no guarantee the issue will be fixed since you don't really know what the bug is in the first place.
1) What is the size of your session database, located at App_Data\Session.db
-rw-r--r-- 1 root root 26M Jul 11 01:05 /opt/ScreenConnect/App_Data/Session.db
2) How many access sessions are calling back to your server?
Currently 4 Support sessions and 2 Access sessions.
3) On average, how many concurrent active sessions (host and guest connected) does your server handle?
Usually I only connect to 1 user at a time but sometimes I use 2 concurrent sessions as that is the maximum that my license can handle.
4) Have you made any customizations to your server (e.g.have you set Control to run behind nginx)?
I run: Drupal, Apache, Dovecot, PhpMyAdmin, ScreenConnect, Perl, PHP, Mysql, Fail2ban on the server primarily. I don't use nginix.
5) What extensions have you installed?
Note the screen captures below which show a whopping 300mb RAM jump in only 1 minute time. All I did was click on 3 conversations from clients and clicked on their sessions.
You are more than welcome to connect to my server to review the issues if you cannot replicate it.
Thank you for looking into this. Yes, mono is 32-bit.
[root@xeon3 vmware:/var/log]# LD_SHOW_AUXV=1 ldd /proc/12596/exe | grep AT_PLATFORM | tail -1AT_PLATFORM: i686
According to this page, 32-bit Linux is supported for ScreenConnect server roles:
Wow, an entire month has gone by and still no response.
Since originally posting this issue, I completely uninstalled and reinstalled the product clean with a brand new configuration file and sessions database, and made only minimal changes to the configuration file. I've documented what I did here:
Mono seemed to be behaving itself up until a few days ago, but now I'm right back where I was - in fact, the problem seems worse. Every click I make on a session eats 1 megabyte of memory. If I review a chat, another 300 megabytes gets eaten. If I review more than 3 chats I get "unknown error" in my browser and mono crashes and restarts on the server.
This is absolutely ridiculous. I've upgraded to the latest edition (ScreenConnect_6.3.13446.6374) and the problem has not been fixed!
I've sent an email to ScreenConnect sales and posted here, and have ZERO help from anyone. My license is going to expire on August 9th, 2017 and it seems I have little recourse but to keep reinstalling the product to "fix" the issue for a unknown duration of time until it creeps up again.
What can be done about this problem? How about connecting to my server and looking at it?
Customer support service by UserEcho