+14
Fixed

Portal still not responding.

Joshua Zukerman 1 year ago updated by Tns 4 months ago 72

Still having the same issue of the portal becoming unresponsive after random periods of uptime. Running version 20.2.29488.7519 on CentOS 6.10 virtual machine, 1 vCPU, 2GB RAM. When the server is running, it is slightly faster, though that may be due to unloading more than half of the clients to a new Windows VM in Azure. I'm keeping this server around due to many offline agents (computers) that don't get powered on frequently. That way I can point them to my new server without having to manually reinstall the client agent.

Answer

-2
PINNED

Hi All, 

A 20.2 stable was posted on the downloads page today. The release date is from July, but it was updated today -- the "release date" is actually the date it was built and is stored in metadata. 


We've reached out to as many on-prem partners on Linux as we could, some which helped us troubleshoot the current stable release. Other issues were environmental, and could not be reproduced. Any future bugs should go through Support like normal so we can address them quickly. 

+1

Well I guess we just need to move the conversation over here...

Is there any update on possibly moving linux to .net core?

+1

.net core is the only fix here.

Still no commitment to migrating, we're probably going to end up moving to Windows as it's now 10 revisions ahead of linux. 

the only move I will doubt about is the move away from connectwise. But I hope I can stay.

I gave up and moved to Server 2019...

Windows is on 20.10 with 20.11 in beta...If they decide to move to .net core I'll move back to linux but I can't wait around for them to figure it out. 

What is the status on this? I spent 13 hours attempting to replace our Linux server with Windows over the weekend, only to determine that our other core business application run 2.5x slower. This is NOT going to work. We NEED a stable Linux version. NOW.

How can things go THAT wrong ?
We are all IT professionals here. Can we have technical feedback from developpers about the issue they are facing and how they progress? is this product in a dead end ?

The Linux seems to be a dead end. Windows seems like a new release every week. 

+1

been several updates to the Win server while we've been waiting here.

To rub salt into the wound I got an email from a Connectwise salesperson at the exact time I was meant to be in a remote session with a client - but couldn't because the session manager had crashed.
I've owned the product since July 2015 and they've NEVER managed to let me know when my subscription is nearly up.
Lack of updates to the Linux server now means I'll have to pay to get the bug fix we've been waiting for over 2 months for. 
I don't want to encourage bad service so it looks like that might be the end for me.
Huge pity because I really think there's a gold mine in the software if they decide to update it

+1

HELLO??????  

WHY o WHY are we complete IGNORED by the company who INVOICES us yearly? WAKE UP PLEASE!!

-2

If someone can reproduce this issue reliably, please email ctrlpm@connectwise.com and we'll setup a time to get on a session. We have been unable to reproduce these periods of unresponsiveness in-house. Thanks!

Also, please see https://control.product.connectwise.com/communities/62/topics/3330-adding-logging-to-your-linux-server. After adding logging to your server, please reach out to us through the email Caitlin posted above and we'll take a look at the logs to see what we can find out. Thanks!

+2

you had a beta group testing this for a few weeks before releasing the 'canary' build,
I'd hope one of those people would be able to help with logging. It's now been 2 months. 
My Support contract has now run out and honestly I'm not going to help any further or pay any more $ until there's a clear commitment to get the product up to date. 
The issue doesn't occur on a fresh build, it creeps in later and is random. It is not reproducible in my experience. 
And please commit some resources to getting this product fixed- if you decide to drop the Linux server you'll be giving up more than a small bunch of complainers- you're giving up options if Windows develops a show stopping bug

+2

I too am still having issues with it randomly stopping responding on 20.2.29488.7519. Decided to look into migrating to Cloud. Turns out this isn't straightforward, as you can only migrate if the on-prem version matches the latest Cloud version, but you literally cannot get the latest Linux on-prem version, as it doesn't exist! Support has told me that to migrate to the Cloud, I need to first migrate to Windows and then migrate to the Cloud! Ha! I'd rather migrate elsewhere than faff about setting up a Windows server just to use for 5 mins.

+2

Why should we migrate to the cloud. We pay for a working solution and we don't get service anymore. 

If this doesn't change, I'll finish my collaboration with connectwise and change to another solution. 

What bothers me the most is that connectwise knows that and still doesn't do anything.

-2
PINNED

Hi All, 

A 20.2 stable was posted on the downloads page today. The release date is from July, but it was updated today -- the "release date" is actually the date it was built and is stored in metadata. 


We've reached out to as many on-prem partners on Linux as we could, some which helped us troubleshoot the current stable release. Other issues were environmental, and could not be reproduced. Any future bugs should go through Support like normal so we can address them quickly. 

+2

Caitlin, are you able to provide any details on the plan to now bring the Linux version back in line with the Windows version? As it's currently stopping us from being able to migrate to Cloud even if we wanted to.

-5

James, and really anyone on the thread, 

If you're currently on Linux and wish to move the cloud, please reach out to me (ctrlpm@connectwise.com) and I'll make arrangements to move you to the cloud without the jump to Windows. Please note that some data may be lost in the transfer. 

+7

Caitlin, you failed to respond to the larger question--namely what are the future plans for Linux?  This year should really have been the time to revamp the core architecture given Microsoft's huge push towards .NET Core (now called .NET 5 and also RTM as of 3 days ago).  The old .NET Framework is now legacy code.  Sure it will still be around for quite a while, but it's not what Microsoft themselves are using anymore and won't be receiving much attention at all.


Microsoft has a rapid iteration cycle planned for future .NET upgrades.  Moving to this newer .NET architecture would highly benefit your Windows and Cloud infrastructure, and of course also would provide direct support for Linux and MacOS without any crazy Mono headaches.


Ideally this migration should have been going on this year with testing to be ready for .NET 5 RTM, but now is the time to finally pull the trigger to avoid years of headaches with a legacy platform that Microsoft doesn't really care about anymore as bugs creep in with future Windows OS releases.  PLEASE DO THIS.  I really can't imagine that it would require a ton of code rewriting since Microsoft has spent a lot of time on making the transition smooth.  You could then put the Mono issue in the grave once and for all and still please your current (and likely future) Linux customers.  You'd even gain MacOS compatibility again.  And of course, Windows users would see performance improvements too.  All on one unified codebase.  This is really the perfect product to benefit from Microsoft's cross-platform .NET vision, and you'd be setting the stage for years of a well-maintained, efficient codebase that would reduce maintenance costs and make customers happy.

Sounds like the date modification is so it will run properly under my expired license, if that's the case thank you. I look forward to getting it installed

Yes, missed that in my post yesterday! We've back dated the release so its eligible for the expired license. Looking forward to your feedback!

+2

WARNING! Do not upgrade to the new version and attempt to update any of your previously installed access clients. It will completely remove the application from the computer.

Hey Ben,

Could you start a new bug report for this? Just don't want things like this to get lost in this thread. Thanks!

Already submitted. Wanted to post this here first so nobody else has to suffer.

Is this bug fixed? I can't find any submitted ticket about it.

NO! This bug is NOT fixed.

+1

Couple of comments-
1. the 'portal not responding' issue is not fixed, but it is maybe 70% better for me. It only affects my work once or twice per day instead of every time I go to use it
2. I was careful about updating clients because of the other bug report- but I upgraded one client and it was fine. After that, I now seem to be unable to re-install any clients. Not sure if it's a version mismatch but it doesn't seem to even attempt the upgrade (from the 20.2 canary version)

I posted this in another thread but I just wanted to let everyone here know that this issue has been identified again as happening with 20.2.  I'm still not sure if it's the exact same issue we previously addressed but it is under active investigation.

+1

interestingly it looks like it they migrated to .Net they could get back Linux and macOS

'The .NET team has efforts to make .NET 5 compatible with Rossetta 2. Native support is a goal for .NET 6, with planning already starting.'

https://blog.jetbrains.com/dotnet/2020/12/11/net-development-on-apple-silicon/

+4

Yeah, that's what I've been saying for the past year throughout this whole fiasco, but they appear to be unresponsive to any suggestions on this issue.  It's quite frankly very surprising to me that they wouldn't be moving in this direction already as part of a general maintenance plan for the software.  It's just mind-boggling that they would still refuse to even discuss the idea of upgrading the .NET dependency given all the issues over the past year.

Apple's move to their own CPU architecture (and Microsoft's immediate plans to support it via future .NET updates) are a perfect example of why the modest investment of keeping up to date with new .NET releases would greatly benefit Connectwise (both with maintenance cost savings and improved performance/compatibility).  Let Microsoft do the work of supporting the various platforms.

@Caitlin, Apple's platform changes likely will affect Connectwise even for MacOS clients in CC.  Even if the existing client software will work under emulation, it will be slower and subject to any bugs created during the emulation process.  Reasons to update your core platform dependencies are only going to continue to add up over time.  The only real reason not to do this is some sad idea that you can try to convert on-premise customers over to your cloud platform to make more money.  But the goodwill lost on your long-term on-premise customers is a much more valuable asset than any small number of on-premise to cloud conversions you might get.  The on-premise option was what made ScreenConnect stand out from the rest of the cloud options long ago.  Having a cloud platform is fine for those that want it, but if you make things hard for your on-premise customers be prepared to see people leave en masse with some other competitor that pops up to fill the void.  And then you'd still likely have to invest in the .NET upgrades anyway in the future even for your cloud platform.  All of this mess could be avoided if you simply invested now in upgrading the dependencies and actually supported your on-premise customers like Connectwise promised to do when they acquired ScreenConnect.

You know.. I have a friend still on 16.04... and he doesn't have any problems with connectwise control..........

+1

Actually decided to try this...  

Installed a fresh copy of ubuntu 16.04.7 LTS in vmware, used E1000 nic.  

tar -czvf screenconnect.tar.gz /opt/screenconnect 


moved the file to the new server


tar -xvf screenconnect.tar.gz 


mv opt/  /opt


Re-ran ScreenConnect Installer 



Will report back in a few if this made any large impact  

(yes all my sessions are fine) 

+1

Decided to move my self-hosted install to Windows. Works great so far.

+1

Still occasionally seeing the web-ui become unresponsive.   it isn't nearly as bad as it was previous to the focusgroup build. 

Here is what I get in the logs while its hanging..

control-01:~# tail -f /var/log/screenconnect

Mono: The request to load the assembly System.Net.Http v4.2.0.0 was remapped to v4.0.0.0

Mono: The request to load the assembly System.IO.Compression v4.2.0.0 was remapped to v4.0.0.0

Mono: The request to load the assembly System.Net.Http v4.2.0.0 was remapped to v4.0.0.0

Mono: The request to load the assembly System.IO.Compression v4.2.0.0 was remapped to v4.0.0.0

Mono: The request to load the assembly System.Net.Http v4.2.0.0 was remapped to v4.0.0.0

Mono: The request to load the assembly System.IO.Compression v4.2.0.0 was remapped to v4.0.0.0

Mono: The request to load the assembly System.Net.Http v4.2.0.0 was remapped to v4.0.0.0

Mono: The request to load the assembly System.IO.Compression v4.2.0.0 was remapped to v4.0.0.0

Mono: The request to load the assembly System.Net.Http v4.2.0.0 was remapped to v4.0.0.0

Event (2021/01/19 11:15:16.641 -05:00, ScreenConnect Web Server, Information): Successfully started service.

Occasionally? It's daily for us. Already happened twice in the last two hours. What the ETA for this fix?

Ben, what version are you running?

The latest Linux version, 20.2.29488.7513

So nice being on Windows now.. my god it is fast. No more sessions thinking I am still connected. No more "time to reboot the server"... =) Guys... if any of you have programmed in C#.. you would know they decided on Dot Net Framework awhile back.. With Mono implementations... Mono... isn't the best these days for C#. And yes... .NET (Linux, OSX, Windows) would be ideal.. but porting an entire program from Dot Net Framework to .NET is not as easy as you guys might think. Either way... Mono...... get off of mono. This program uses a ton of threading and Mono sucks at threading. It was just until after Dot Net Framework 4.5 (4.7) that threading issues were improved.. so imaging threading with Mono. But you sure as hell don't want the client to be in .NET... be a MUCH larger download.. most folks don't have that installed. Once I realized that they forked Mono.. writing was on the wall. Maybe mono and newer Libc, systemd, kernel... are too much for that fork. But maybe 16.04 works... that is what I think.. but I don't want to use something that old. I do miss my fail2ban setup though. Maybe some exploit that might of worked.. won't work on Mono because it will just crash a thread. Running my setup on Digital Ocean... with Windows 10 If you go off the guides on the internet to do Digital Ocean and windows 10, use the latest iso download, not links on the guides.. you won't boot newer then 1809.. as their driver on those guides is not signed with the newer SHA256. I have an EC2 account but decided to go with Digital Ocean still. =) Digital Ocean's webconsole works with a GUI in Windows.. Pretty cool.. EC2 requires RDP when setup. Digital Ocean has a strict 2fa policy. When I was in jail waiting for trial (google it), my wife tried to get into my Digital Ocean to pay the bill, but couldn't because of 2fa. Even with my drivers license and etc, they told her no. Looking back, that made me pretty happy. They reset it for me eventually, but it took so long I created a new droplet. I did have her backup my database.. over a jail phone I told her how to use putty to create a tar.gz and then had her use scp to download it.. Took like an hour. Nite! =)

Oh.. I have IIS doing SSL Offloading with URL Rewrite... this command helps preserve headers. "Notes"

"C:\Windows\System32\inetsrv\appcmd.exe" set config -section:system.webServer/proxy /preserveHostHeader:"True" /commit:apphost
-1

So.... decided to turn off the IIS stuff and just run straight screenconnect with SSL. Something with cookies. When I logout it doesn't always log me out when I used IIS. stuff. 

+6

Hey Justin,

With all due respect this is a thread about ongoing issues with the Linux on prem version. We're very happy for you if it works for you under Windows, but that doesn't help our issue. 
If I had to guess, I'd say the dev team made a deal where they could release one 'golden' linux version, then drastically ramp up the Windows version- perhaps on the understanding that when up to date with the latest .Net they might even be able to back fill to linux. 
It's been a disaster- they've taken a premium, class leading product and killed it by neglect. 

Well.. as I said in earlier posts.. try 16.04 LTS.. my buddy uses it without a hitch. I was on a beta linux version they removed from the site.. and I doubt they come up with another update.

This server is running additional services, where at least 18.04 is required so we are running 18.04.5 LTS

+2

i require the latest update on this ongoing and debilitating issue. Please produce the evidence that this is being rectified post haste.

Curious for the Ubuntu 18.04 users out there.  Are you guys using VMXNET3 for the ethernet card or E1000.   Noticed that it seems like screenconnect is more stable using E1000 virtual nic over the past few days.   Wondering if others wanted to try to switch and see if they are seeing the same?   

We are using VirtualBox. It doesn't matter what network controller we use, today ScreenConnect cut out at least 3 times during critical moments. It's trying myself and my staff nuts.

+1

Why is this bug report marked as fixed?

+1

Nothing has changed, no new release with fixed bug. It's just a bad joke to mark this bug as fixed.

It is pretty evident at this stage that the plan is at once both a money grab (pay us to move you to cloud or migrate to Windows) and an attempt to phase out non-Windows systems. Having just binge-read several threads spanning the last 8 months and seeing some frankly patronizing responses from staff, I'm looking for alternatives. I absolutely can migrate to windows, though at the cost of unnecessary license fees, but offloading your customers to some other system is wholly inappropriate if you claim to support the system they're currently on, and if this is their idea of support they're clearly not worth investing in if you hope to keep your systems on Windows. I can recommend this service for people who have Windows licenses at their disposal but not for anyone else. 

+1

Reporting back after 1 day.    


Actually decided to try this, as suggested by Justin Shafer above.  

Installed a fresh copy of ubuntu 16.04.7 LTS in vmware, used E1000 Based NIC.    4 CPU, 4GB RAM, 60GB disk. 

went to problematic ubuntu 18.04 instance and ran:

tar -czvf screenconnect.tar.gz /opt/screenconnect

copied the file to the new server (ubuntu 16.04.7) in the /tmp/ directory 

cd /tmp/

tar -xvf screenconnect.tar.gz

mv opt/ /opt

Re-ran ScreenConnect Installer

wget https://d1kuyuqowve5id.cloudfront.net/ScreenConnect_20.2.29488.7513_Release.tar.gz

tar -xvf ScreenConnect_20.2.29488.7513_Release.tar.gz

cd ScreenConnect_ <tab to auto complete rest>

./install.sh

went though installer.

(yes all my sessions are fine)

So far I can report that it hasn't crashed yet.    1 full day of uptime. 



top - 10:14:33 up 1 day, 12:08, 1 user, load average: 0.10, 0.08, 0.08

Tasks: 196 total, 1 running, 195 sleeping, 0 stopped, 0 zombie

%Cpu(s): 1.8 us, 0.6 sy, 0.0 ni, 97.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem : 4045940 total, 1821940 free, 370448 used, 1853552 buff/cache

KiB Swap: 1003516 total, 1003516 free, 0 used. 3352620 avail Mem



PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

5567 root 20 0 2459900 340612 56616 S 9.0 8.4 162:05.55 mono

763 root 20 0 116248 9792 8600 S 0.3 0.2 1:40.30 vmtoolsd

7815 root 20 0 41796 3808 3180 R 0.3 0.1 0:00.06 top

1 root 20 0 37832 5852 4032 S 0.0 0.1 0:03.20 systemd

2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd

3 root 20 0 0 0 0 S 0.0 0.0 0:00.35 ksoftirqd/0

5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:+

7 root 20 0 0 0 0 S 0.0 0.0 0:50.06 rcu_sched

8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh

9 root rt 0 0 0 0 S 0.0 0.0 0:00.12 migration/0

10 root rt 0 0 0 0 S 0.0 0.0 0:00.72 watchdog/0

11 root rt 0 0 0 0 S 0.0 0.0 0:00.67 watchdog/1

12 root rt 0 0 0 0 S 0.0 0.0 0:00.11 migration/1

13 root 20 0 0 0 0 S 0.0 0.0 0:00.77 ksoftirqd/1

15 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:+

16 root rt 0 0 0 0 S 0.0 0.0 0:00.66 watchdog/2

17 root rt 0 0 0 0 S 0.0 0.0 0:00.11 migration/

If anyone is interested I can keep posting findings.  



+1

Up 4 days and counting with screenconnect on ubuntu 16.04.7  



root@help:~# uname -a

Linux help 4.4.0-186-generic #216-Ubuntu SMP Wed Jul 1 05:34:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

root@help:~#

root@help:~#

root@help:~# top

top - 08:02:01 up 4 days, 9:55, 1 user, load average: 0.03, 0.07, 0.08

Tasks: 200 total, 1 running, 199 sleeping, 0 stopped, 0 zombie

%Cpu(s): 1.5 us, 0.6 sy, 0.0 ni, 97.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem : 4045940 total, 1692108 free, 462912 used, 1890920 buff/cache

KiB Swap: 1003516 total, 1003516 free, 0 used. 3259540 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

5567 root 20 0 2533628 428052 55836 S 31.2 10.6 532:20.59 mono

13792 root 20 0 41796 3840 3212 R 6.2 0.1 0:00.01 top

1 root 20 0 37832 5852 4032 S 0.0 0.1 0:04.30 systemd

2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd

3 root 20 0 0 0 0 S 0.0 0.0 0:01.01 ksoftirqd/0

5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:+

7 root 20 0 0 0 0 S 0.0 0.0 2:27.49 rcu_sched

8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh

9 root rt 0 0 0 0 S 0.0 0.0 0:00.12 migration/0

10 root rt 0 0 0 0 S 0.0 0.0 0:02.12 watchdog/0

11 root rt 0 0 0 0 S 0.0 0.0 0:01.97 watchdog/1

12 root rt 0 0 0 0 S 0.0 0.0 0:00.12 migration/1

13 root 20 0 0 0 0 S 0.0 0.0 0:02.16 ksoftirqd/1

15 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:+

16 root rt 0 0 0 0 S 0.0 0.0 0:01.94 watchdog/2

17 root rt 0 0 0 0 S 0.0 0.0 0:00.12 migration/2

18 root 20 0 0 0 0 S 0.0 0.0 0:01.57 ksoftirqd/2

well nice, but sucks to use 16.04 which will be EOL in about 1 month

+1

6 days without any reboot or service restart on ubuntu 16.04.7  

yes agree it stinks that it's almost EOL. 

top - 08:50:17 up 6 days, 10:43, 1 user, load average: 0.17, 0.13, 0.09

Tasks: 193 total, 2 running, 191 sleeping, 0 stopped, 0 zombie

%Cpu(s): 1.7 us, 0.4 sy, 0.0 ni, 97.8 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st

KiB Mem : 4045940 total, 1554840 free, 563428 used, 1927672 buff/cache

KiB Swap: 1003516 total, 1003516 free, 0 used. 3157156 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

5567 root 20 0 2635156 533664 56840 S 8.3 13.2 807:58.84 mono

19380 cjcatuc+ 20 0 41804 3764 3096 R 0.3 0.1 0:00.13 top

1 root 20 0 37832 5852 4032 S 0.0 0.1 0:05.17 systemd

2 root 20 0 0 0 0 S 0.0 0.0 0:00.03 kthreadd

3 root 20 0 0 0 0 S 0.0 0.0 0:01.53 ksoftirqd/0

5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H

7 root 20 0 0 0 0 S 0.0 0.0 3:38.50 rcu_sched

8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh

9 root rt 0 0 0 0 S 0.0 0.0 0:00.13 migration/0

10 root rt 0 0 0 0 S 0.0 0.0 0:03.10 watchdog/0

11 root rt 0 0 0 0 S 0.0 0.0 0:02.89 watchdog/1

12 root rt 0 0 0 0 S 0.0 0.0 0:00.12 migration/1

13 root 20 0 0 0 0 S 0.0 0.0 0:03.26 ksoftirqd/1

15 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H

16 root rt 0 0 0 0 S 0.0 0.0 0:02.84 watchdog/2

17 root rt 0 0 0 0 S 0.0 0.0 0:00.12 migration/2

18 root 20 0 0 0 0 S 0.0 0.0 0:02.26 ksoftirqd/2

20 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/2:0H

21 root rt 0 0 0 0 S 0.0 0.0 0:02.65 watchdog/3

22 root rt 0 0 0 0 S 0.0 0.0 0:00.12 migration/3

23 root 20 0 0 0 0 S 0.0 0.0 0:02.94 ksoftirqd/3

25 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/3:0H

26 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs

27 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns

28 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 perf

29 root 20 0 0 0 0 S 0.0 0.0 0:00.83 khungtaskd

30 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback

31 root 25 5 0 0 0 S 0.0 0.0 0:00.00 ksmd

32 root 39 19 0 0 0 S 0.0 0.0 0:00.00 khugepaged

33 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 crypto

34 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kintegrityd

35 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset

+1

Well... I guess my friend was right. 

So.. went to see friend.. he is running 14.04, not 16.04... =) Now he is on windows.

16.04.07  Still remains stable.   19 days later....

If your on linux -  I think I'd recommend you go to 16.04.07 LTS even if it expires soon

root@help:~$ uptime

10:22:21 up 19 days, 11:15, 1 user, load average: 0.29, 0.27, 0.27

root@help:~$


root@help:~$ top

top - 10:23:47 up 19 days, 11:17, 1 user, load average: 0.21, 0.24, 0.26

Tasks: 193 total, 1 running, 192 sleeping, 0 stopped, 0 zombie

%Cpu(s): 3.3 us, 1.2 sy, 0.0 ni, 95.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem : 4045940 total, 599172 free, 1077052 used, 2369716 buff/cache

KiB Swap: 1003516 total, 1003148 free, 368 used. 2633248 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

5567 root 20 0 3109668 0.994g 55284 S 17.9 25.8 3645:49 mono

1716 cjcatuc+ 20 0 41796 3796 3180 R 0.3 0.1 0:00.10 top

1 root 20 0 37832 5852 4032 S 0.0 0.1 0:10.40 systemd

2 root 20 0 0 0 0 S 0.0 0.0 0:00.11 kthreadd

3 root 20 0 0 0 0 S 0.0 0.0 0:04.66 ksoftirqd/0

5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:+

7 root 20 0 0 0 0 S 0.0 0.0 13:53.04 rcu_sched

10:22:21 up 19 days, 11:15, 1 user, load average: 0.29, 0.27, 0.27

root@help:~$

+5

I came back to say the following in case Connectwise read this-

I've paid my maintenance on the basis that Connectwise have said they will continue to release Linux server updates.
I've also moved my Server to Windows but I hope this is temporary because I am REALLY uncomfortable with this current requirement...

Unfortunately, this issue is still occurring with 20.3.31734.7778. Less frequently though, it seems it's down to "only" once or twice a day. 

+4

i require the "FIXED" tag removed from this thread. The issue is still ongoing.

+1

was to be expected, had they only said this last year instead of wasting our precious time with beta testing.

ConnectWise should really be ashamed of this.

Your supporters here have been saying for over a year to get this moved to .net core, instead you waste their time with a half working beta and throw in the towel...

You guys might as well give up on android guests too, since that hasn't worked properly in 3 years or so. 

this document is released more than a week ago. But no officials use this channel to talk to its linux customers directly. Aren’t we too unimportant?

Well it seems it is time to seek an alternative. Since the folks at ConnectWise don't monitor this post, I would like to know if any of you have tried SimpleHelp?

SimpleHelp is basically not bad. There are many functions that are identical to ScreenConnect. I really like the clear arrangement of the many remote computers. You can create a real tree structure. Personally, I don't like the fact that support clients have to be installed everywhere. I am out and about in a lot of working places and don't always have a support client on the customer computer to quickly adjust something. But maybe you have to change the workflow here. I also think the quality of the remote desktop transmitted is better with Screenconnect. I have media production companies and I can even see video data through Screenconnect. With SimpleHelp, the data is updated much less. Almost like photos that are then updated.

Ultimately, it depends on which customers you want to serve with it. Simple IT support goes without problems with SimpleHelp.

is simplehelp OnPremise?   if not then the solution is not for me.   Personally do not trust cloud solutions.  

Not sure why you wouldn’t just port your server to windows… it is what it is at this point.  

My 16.04 Ubuntu install was still running good but I moved to windows anyways for the long term aspect of getting updates.   I do find it sad that after all this time it’s come to this though.  And I personally can’t stand the fact that I am running this on windows it’s my first and hopefully only windows server in my environment.  (Actually windows 10 though) 


SimpleHelp it is onPremise and needs only a very small linux server. 

routeserver: Thank your very much for the information.

Chris Catucci: You are right, Screen Connect On-Prem on Windows is a solution but to be honest the way ConnectWise handled its Linux clients over the last year left a bad taste in my mouth. If I can find an alternative, I will simply leave the ConnectWise boat! 

Commenting disabled