| Summary: | asterisk uses 100% cpu (fresh install) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Wolfgang Rupprecht <wolfgang.rupprecht> |
| Component: | asterisk | Assignee: | Jeffrey C. Ollie <jeff> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | itamar, jeff |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-09-20 16:53:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Wolfgang Rupprecht
2011-06-26 22:30:46 UTC
First, please try 1.8.4.3 which should be in updates-testing. Then can you go into the asterisk console and enable debugging to see of there's anything obvious? Updating: asterisk x86_64 1.8.4.3-1.fc15 updates-testing 2.6 M Updating for dependencies: asterisk-alsa x86_64 1.8.4.3-1.fc15 updates-testing 83 k asterisk-festival x86_64 1.8.4.3-1.fc15 updates-testing 79 k asterisk-jabber x86_64 1.8.4.3-1.fc15 updates-testing 145 k asterisk-voicemail x86_64 1.8.4.3-1.fc15 updates-testing 80 k asterisk-voicemail-plain x86_64 1.8.4.3-1.fc15 updates-testing 147 k arbol*CLI> core set debug 100 Core debug was 0 and is now 100 arbol*CLI> core set verbose 100 Verbosity was 1 and is now 100 arbol*CLI> <no output of any type> The cpu that asterisk is running on (this is a 4-core system) is still 100% used up. Top shows 75% idle (1 of 4 cores in a spin loop) and shows 100% for asterisk's CPU usage in the bottom half of the display. Is there something specific I should turn on to trace where asterisk is chewing up the CPU? Strace didn't show anything the last time I tried it indicating it is looping in user space. I don't normally use anything but the core package so it's probably something in one of the other packages that you have that has a bad default config that is driving the CPU usage up. Try removing the subpackages one at a time and see what happens. Also check the audit logs to see if there are any selinux AVCs. "ausearch -x /usr/sbin/asterisk" should filter out the uninteresting stuff. Loaded plugins: langpacks, presto, refresh-packagekit
Installed Packages
asterisk.x86_64 1.8.4.3-1.fc15 @updates-testing
asterisk-debuginfo.x86_64 1.8.4.3-1.fc15 @updates-testing-debuginfo
Available Packages
...
I've removed all the asterisk-* packages except the base and the debuginfo. I still see the looping.
I wonder how my system is different from yours. Are you testing on a 64-bit OS?
Sealert is currently nonfunctional. Seems someone broke a library api.
Opps, sealert hit an error!
Traceback (most recent call last):
File "/usr/bin/sealert", line 692, in <module>
run_as_dbus_service(username)
File "/usr/bin/sealert", line 112, in run_as_dbus_service
app = SEAlert(user, dbus_service.presentation_manager, watch_setroubleshootd=True)
File "/usr/bin/sealert", line 326, in __init__
from setroubleshoot.browser import BrowserApplet
File "/usr/lib64/python2.7/site-packages/setroubleshoot/browser.py", line 46, in <module>
import report.io.GTKIO
ImportError: No module named GTKIO
Looking at the /var/log/audit/audit.log file directly I don't see any avc's (or anything) between the start and stop printfs.
type=SERVICE_START msg=audit(1309208473.597:290): user pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="asterisk" exe="/bin/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1309208855.958:291): user pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="asterisk" exe="/bin/systemd" hostname=? addr=? terminal=? res=success'
One difference that we may have in our systems is that I have 1) multiple network inferfaces and I have ipv6 enabled and in use. I don't have multiple interfaces on my asterisk systems but I do use ipv6. One difference is that I usually don't start asterisk up until after I've done some basic configuration, especially SIP. One other way to track down the source of the problem is to unload individual modules (or block them from loading in the first place) to see which one may be causing the problem. Can you try adding the following lines to /etc/asterisk/modules.conf and see if it fixes this problem? noload => chan_mgcp.so noload => res_pktccops.so See bug#658431 for more information. Adding the two noload lines did the trick. fixed. thanks! *** This bug has been marked as a duplicate of bug 658431 *** |