I have the exact same problem as in the following thread. My CPU load is between 10-20%.
Not 100%. There was never any resolution to this. Disabling sangomartapi module and then fwconsole restart initially worked even though it doesn’t actually fix the problem that module is causing. I also did the things a poster said at the end and then the problem came back. Now it is still a problem regardless of whether I have sangomartapi module installed or not or regardless of whether it is in the pm2 list or not.
Ok so this started after I restored a backup from FreePBX v14 trying to migrate to a new FPBX17 server. I reverted back to the FPBX17 backup and the high CPU goes away. So it’s related to the legacy restore from the FreePBX v14 server. I am not sure where to begin trying to troubleshoot this.
Hi @SamShomi Are you seeing the issue due to SangomaRTAPI module? If you are not using this module then please disable/uninstall sangomartapi.
If you are using this module and seeing this process consuming entire cpu/mem then can you please raise a commercial module support ticket so we can connect to your server to debug further.
Or if you can share your setup details or some steps to reproduce in-house that also would be helpful for us to try locally.
Thanks
may be you have to monitor the htop output to find out first which process is consuming the cpu, is that nodejs or mariadb or php or any other linux process.
once process is identified then you can try to dig further to see what that specific process is doing causing high cpu.
The 10-20% CPU load is caused by the following on an idle server with no calling and sangomartapi module uninstalled.
node /var/www/html/admin/modules/ucp/node/index.js
node /var/www/html/admin/modules/pm2/node/node_modules/pm2/lib/ProcessContainerFork.js
If I disable ucp module then the load problem goes away. I tried downloading and re-installing pm2 and ucp.
Thanks for the help @kgupta .
It appears that it was a self signed certificate issue related to backup/restore from legacy FPBX. Looking at /var/log/asterisk/ucp_err.log I saw the following error repeated.
2024-08-05 13:56 +00:00: Error: error:0A00018F:SSL routines::ee key too small
2024-08-05 13:56 +00:00: at node:internal/tls/secure-context:70:13
2024-08-05 13:56 +00:00: at Array.forEach (<anonymous>)
2024-08-05 13:56 +00:00: at setCerts (node:internal/tls/secure-context:68:3)
2024-08-05 13:56 +00:00: at configSecureContext (node:internal/tls/secure-context:157:5)
2024-08-05 13:56 +00:00: at Object.createSecureContext (node:_tls_common:117:3)
2024-08-05 13:56 +00:00: at Server.setSecureContext (node:_tls_wrap:1471:27)
2024-08-05 13:56 +00:00: at Server (node:_tls_wrap:1335:8)
2024-08-05 13:56 +00:00: at new Server (node:https:76:3)
2024-08-05 13:56 +00:00: at Object.createServer (node:https:120:10)
2024-08-05 13:56 +00:00: at Server (/var/www/html/admin/modules/ucp/node/lib/server.js:106:19) {
2024-08-05 13:56 +00:00: library: 'SSL routines',
2024-08-05 13:56 +00:00: reason: 'ee key too small',
2024-08-05 13:56 +00:00: code: 'ERR_SSL_EE_KEY_TOO_SMALL'
2024-08-05 13:56 +00:00: }
Deleting the self signed certificate in certificate manager and recreating it did not correct the problem. Activating sysadmin module and importing the newly created self signed certificate did appear to finally correct the problem.
1 Like
Nice catch @SamShomi .
I migrated a FPBX16 server and the same thing happened. It should be easy to reproduce just by creating a self-signed certificate on FPBX16 and then doing backup/restore to FPBX17.
This is probably something that needs to be addressed in the backup/restore module unless you want to answer lots of support questions and bug reports as other people run into this.
1 Like
in August 2024, why would anyone expect a self signed certificate to be acceptable by anything ?
Raised [improvement]: Review restoring the certificates from the backup · Issue #347 · FreePBX/issue-tracker · GitHub to review if we really have to restore the certs ? Feel free to add your comments/feedback in the mentioned jira @SamShomi .
Thanks
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.