As I have now discovered by chance, I have recently had the same problem (30% of an 8-core CPU and 11% RAM of 12 GiB).
WIO has worked well for several years now and regularly sent warnings via email when a computer failed. Emails about OpenVPN connections were also sent correctly.
The problem probably occurred when I installed the update 2.27 core 182 a few weeks ago (previously I [probably] had 2.27 core 178 on it), because the day of the update was “Last checked” in WIO.
I noticed it now when I installed IPFire (now updated to 2.29 core 184) on new hardware and imported the backup of the previous system.
Uninstalling, reinstalling and setting up WIO again without using the backup didn’t bring any improvement.
If I “Enable OpenVPN RW and IPsec Statusmails?” deactivate and then kill the viovpn.pl process and then activate “Enable OpenVPN RW and IPsec Statusmails” again, then it works again for a few hours.
You can also easily identify the problem via the GUI, as “Last checked” is no longer current in the event of an error.
I activated fcron logging and found the following in the log in the event of an error:
I hope I can contribute something to the solution with the information. The emails about when a VPN connection was established would be very important to me.
No change has been made to the WIO code in the period CU178 to CU184
The last code change to WIO was in Aug 2020, which was CU148.
When you say new hardware, what was the difference in the hardware. Did both systems have the same cpu architecture?
Your logs indicate a problem with a file in the /etc/fcron.minutely/ directory.
Can you confirm that you only have the wio helper script in that directory. It will be labelled wio and be around 400 Bytes large.
Presuming that you have activate logging enabled in the WIO Configuration page.
If you look in the WUI menu Logs - System Logs and then select Who Is Online? in the drop down box labelled Section: and then press the Update button, are there any messages in those logs indicating any problems.
In the past I used to have problems with WIO that resulted from tests using FQDNs and a failing unbound service on the firewall itself. Sometimes (a dozen or so core updates ago) unbound just stopped and needed a restart.
As soon as the FQDNs did not resolve, I received an alarm for every host in the list. Changing the WIO tests to IP only as a workaround was okay as long as unbound was causing troubles. Now everything is working as designed again.