On the dashboard CPU status, I’m getting a steady 100% indication.
Other indications of CPU usage indication less than 20%.
Running 2.3.1.5 over Asterisk SVN-branch-1.2-r82334 on Ubuntu 6.06.2. All of a sudden (probably–could I have missed it earlier?) CPU usage goes to 100%. Top shows CPU usage to be under 30% pretty much all the time. It looks like this is an indicator fault rather than a CPU problem, but does anyone have any suggestion about making the indicator work right?
TIA,
David Mitchell
IslandWood
It appears this might be a disconnect between the FreePBX code and the way Ubuntu calculates CPU usage. Can someone point to the location in the code where the server information is gathered? I’d like to take a shot at fixing it.
Thanks,
David Mitchell
IslandWood
Look in admin/modules/dashboard/phpsysinfo/*
The method used is loadavg() (which file depends on what OS it detects).
The code that actually displays it is in …/dashboard/page.index.php, line 186.
FreePBX 2.5.1.1 on CENTOS 5. The code that generates the value in class.Linux.inc.php has a couple of small flaws. The code does a ‘cut’ on the result of a vmstat, and uses the value in positions 73-74 to get the idle CPU percentage, and then subtracts that from 100 to get the active CPU percentage.
I did some testing and found that the vmstat command sometimes has such high values in previous columns that the values get shifted to the right. So if everything gets pushed to the right by 1 char, what was “98” percent idle now becomes “9” percent idle, and thus causes the high CPU to be displayed on the status screen.
The other bug is that because the code is only pulling two chars, when the machine reports 100% idle, the code only sees “10”.
To resolve the problem I changed the cut command to an awk:
OLD: $results[‘cpupercent’] = 100 - exec(“vmstat -n 1 2 | tail -1 | cut -c 73-74”);
NEW: $results[‘cpupercent’] = 100 - exec(“vmstat -n 1 2 | tail -1 | awk {‘print $15’}”);
This may not work for all OS’s but it works fine in CENTOS 5.
I wonder if one of the developers would be kind enough to make this change in a future branch.
Regards, Andrew.
Andy, Please post this as a bug against the dashboard and attach your fix. You can find the way to reporting a bug along the bottom of every page under development click on “Bug/Feature Request”.
Things get lost way to easy here in the forums to kept track of but they never get lost in the bug tracker.
Thanks
Bug# 3614.
Regards, Andrew.
Currently running FreepBX 2.6.0 Beta2.2 on a Pentium 3.0GHZ 2MB RAM with Redhat CentOS release 5.3
The only thing configured is the outbound trunk which tested OK.
The problem I have noticed is that after every 3days of continuous operation of the system the CPU load average gets to 100% with difficulty in accessing the admin interface of FreePBX. But after reboot the system resumes normal with immediate access to the admin GUI. Please help
I have the same issue, though on 2.1.3, the zCPU maxes ot to 100% and calls take around 20 secs before they start ringing.
Recently noticed that FreePBX was constantly reporting high CPU usage (100%) after being up for a few hours. I was using PBX in a Flash 1.7.5.6, which uses Asterisk 1.8.3.3 and FreePBX 2.8.0.x.
When I investigated, I found that ps aux showed that whois was using 94% trying to lookup an internal IP address that I recognized as an old ATA that I wasn’t using anymore (but never disconnected, b/c its at a remote site connecting via a VPN). When I reinstalled FreePBX, I didn’t create a trunk for the ATA because I don’t use it anymore, but it kept trying to access anyway, and so Fail2ban kept banning it and sending an e-mail with a whois of my private IP. Naturally, the whois server got tired of responding to whois, so it stopped (or whois crashed). This apparently prompted whois to use 94% of my CPU.
While this was apparently caused by my improper configuration, the same result could be caused by a hacker. If an attacker can cause whois to use 94% of my CPU time, he’s accomplished a DOS without even reallly trying.
I researched the issue and found that there were several bug reports against fail2ban concerning this issue. For now, the solution seems to be to modify jail.conf to remove the whois part of the notification e-mail.
Here’s a example of a bug report I found on the issue:
https://bugzilla.redhat.com/show_bug.cgi?id=469412
The moral of this story is that if you’re having this phenomenon, you might want to look and see if you have any network devices, ATAs, phones, etc. that are trying to register even though they don’t have proper permissions. Alternatively, you can whitelist your local IP addresses using jail.conf. Or you can disable the e-mail option by putting a # in front of the sendmail-whois line under [asterisk] in jail.conf and stop the whois requests…