[asterisk-users] Asterisk Crash
Josiah Bryan
jbryan at productiveconcepts.com
Wed Sep 3 15:04:16 CDT 2008
Alright, praise <diety>, I think I've got an idea on *what* its crashing
on- I've tested the change below and Asterisk no longer crashes at that
point. I'm crosing my fingers hoping that it doesn't crash anywhere else.
Bottom line: Asterisk is crashing when AGI tells it to 'Dial' for an
active call that the operator just transfered.
Details: I've got an AGI script that routes the call to one of three
receptionists based on call load for that SIP device (uses manager to
show channels to get a count of how many calls each operator is handling
at that moment. Got that so far? Okay.
Here's the basic flow: The AGI script figures out which SIP device to
send the call to. It sends an agi exec command to Asterisk to Dial
$device|45. Operator answers call, does her script. Operator then
presses transfer button on her phone to transfer to whomever the call is
destined for. Somewhere after the time she presses transfer, asterisk
seems to go back to executing the AGI script.
Now, the next command after the Dial $device|45 is another 'Dial' to a
backup operator (normally myself or another person in the IT department)
- that way we can be sure the call gets to a person even if the
operators don't answer. Anyway, as soon as the second Dial is executed
to the backup SIP device (whoever is on duty at that time), asterisk
crashes and burns.
What it seems is that even though the call went thru AGI, AGI dialed the
operator, operator xfered to dest exten - as soon as the operator let go
of the call (by xfering), asterisk let the AGI continue...almost as if
the operator didn't answer.
Normally, in my pre-1.4 environment, the second Dial in the AGI was
rarely reached - it was only reached if the first operator didn't answer
- or if the call was hungup, before SIGHUP was received.
But now, post-1.4, it seems to "fall through" so to speak as soon as the
operator transfers the call.
As a work around, I've just disabled the second Dial command. All the
calls on my server just cleared out and I just tested it - and yes, that
was indeed the problem.
Any ideas why Dial seems to fall thru after the operator xfers the call
or if I can even do anything about that?
Thanks for your help and your time with all of this.
Cheers!
-josiah
Josiah Bryan wrote:
> "From" was a CVS-HEAD version from way back pre 1.2 days, sometime in
> the 1.0 days (I think.)
>
> I've reviewed my dialplan based on the and UPGRADE.txt notes (and
> UPGRADE-1.2 notes) and I've made all the necessary changes (e.g. SetVar,
> etc.) - really not much was affected in the dialplan. I'm just doing the
> basic "calls come in to receptionist, she transfers to users extensions"
> paradigm.
>
> yum update is still doing header downloads for the upgrade transaction,
> and I havn't seen a kernel update come through yet - I'll keep an eye out.
>
> As far as DAHDI - didn't know that - googling turned up the digium blog
> on the topic, but the linked page
> (http://www.asterisk.org/zaptel-to-dahdi) was empty content-wise. I did
> use a fresh build of zaptel-1.4 (svn r4506) from
> http://svn.digium.com/svn/zaptel/branches/1.4 for the asterisk 1.4 upgrade.
>
> My watchdog process still is reporting frequent crashes of asterisk
> (most recent at 12:35 EST - they are on average an hour or less apart -
> some 5 or 10 minutes apart.)
>
> Suggestions for further debugging? /var/log/asterisk shows a bunch of
> log files - event_log is blank, messages is just warnings from the
> console - but NOTHING in /var/log/asterisk/messages from around the
> crash times (e.g. at 12:35 EST in messages there is nothing, last msg
> was at 12:01 and next msg was at 12:36 indicating a restart of asterisk
> with "cdr.c: CDR simple logging enabled" message.).
>
> Any way to get asterisk to tell me *why* or what app is causing the
> crash or termination?
>
> Thanks for your help with this mess. Cheers!
> -josiah
>
>
>
> Andrew Latham wrote:
>> I have had issues with 2.6.9 in the past but it sounds like that is
>> not you issue. You upgraded from ___?___ to 1.4.21.2 and it crashes.
>> If you upgraded from 1.2 did you check your dialplan to see if the
>> commands are depreciated and you also understand that a lot has change
>> on zaptel which is now DAHDI........
>>
>>
>>
>>
>> On Wed, Sep 3, 2008 at 11:43 AM, Josiah Bryan
>> <jbryan at productiveconcepts.com> wrote:
>>> Hardware wise, I've got a 1.5 GHz processor with 256 MB RAM running FC3
>>> (kernel 2.6.9-1.667). (System output of uname -a and more is below the
>>> closing.)
>>>
>>> I've got two wctdm PCI cards running 4 FXO modules each:
>>> pci:0000:02:08.0 wctdm+ e159:0001 Wildcard TDM400P REV E/F
>>> pci:0000:02:0a.0 wctdm+ e159:0001 Wildcard TDM400P REV E/F
>>>
>>> As far as FC3 - I believe last yum update was ran on 6/01 of this year -
>>> - good suggestion, I'll re-run it right now as I type this...okay, yum
>>> update running.
>>>
>>> The only dmesg output that even looks odd is:
>>> post_create: setxattr failed, rc=28 (dev=dm-0 ino=451747)
>>> post_create: setxattr failed, rc=28 (dev=dm-0 ino=451748)
>>>
>>> Other than that, the only other dmesg output since reboot (this morning
>>> 8am or so) is some selinux deny messages related to snmpd and httpd.
>>>
>>>
>>> Suggestions? Thank you for taking the time to look at all of this.
>>>
>>> Regards,
>>> -josiah
>>>
>>>
>>> Here's uname, free, and /proc/cpuinfo:
>>>
>>> [root at asterisk asterisk]# uname -a
>>> Linux asterisk.productiveconcepts.com 2.6.9-1.667 #1 Tue Nov 2 14:41:25
>>> EST 2004 i686 i686 i386 GNU/Linux
>>>
>>> [root at asterisk asterisk]# free
>>> total used free shared buffers cached
>>> Mem: 255652 253416 2236 0 1380 81220
>>> -/+ buffers/cache: 170816 84836
>>> Swap: 524280 8340 515940
>>>
>>> [root at asterisk asterisk]# cat /proc/cpuinfo
>>> processor : 0
>>> vendor_id : GenuineIntel
>>> cpu family : 15
>>> model : 1
>>> model name : Intel(R) Pentium(R) 4 CPU 1.50GHz
>>> stepping : 2
>>> cpu MHz : 1483.674
>>> cache size : 256 KB
>>> fdiv_bug : no
>>> hlt_bug : no
>>> f00f_bug : no
>>> coma_bug : no
>>> fpu : yes
>>> fpu_exception : yes
>>> cpuid level : 2
>>> wp : yes
>>> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
>>> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
>>> bogomips : 2924.54
>>>
>>>
>>>
>>> Andrew Latham wrote:
>>>> What type of hardware are you using? When is the last time you upgraded Fedora?
>>>>
>>>> "core set verbose 6" should get you anything you need. Have a look at
>>>> the "dmesg" output.
>>>>
>>>>
>>>>
>>>> On Wed, Sep 3, 2008 at 10:14 AM, Josiah Bryan
>>>> <jbryan at productiveconcepts.com> wrote:
>>>>> Hello, folks -
>>>>>
>>>>> Just upgraded to 1.4.21.2 on FC3. Now I've got random crashing of the
>>>>> 'asterisk' process. I thought it was due to mpg123 and music on hold -
>>>>> so I disabled all MOH classes in musiconhold.conf - but still random
>>>>> crashing!
>>>>>
>>>>> Here's a transcript from the console. Right at the "Disconnected"
>>>>> message, the asterisk process had crashed. I've got a watchdog that
>>>>> automatically restarts the process, but that still means all calls were
>>>>> lost.
>>>>>
>>>>> Any advice on how to troubleshoot or diagnose??
>>>>>
>>>>> Thanks!
>>>>> -josiah
>>>>>
>>>>>
>>>>>
>>>>> asterisk*CLI> set verbose 99
>>>>> Verbosity was 1 and is now 99
>>>>> The 'set verbose' command is deprecated and will be removed in a future
>>>>> release. Please use 'core set verbose' instead.
>>>>> -- Music class default requested but no musiconhold loaded.
>>>>> -- Executing [213 at playground:1] Macro("SIP/op-1-0902f218",
>>>>> "stdexten|213|SIP/213") in new stack
>>>>> -- Executing [s at macro-stdexten:1] GotoIf("SIP/op-1-0902f218",
>>>>> "1?999|1") in new stack
>>>>> -- Goto (macro-stdexten,999,1)
>>>>> -- Executing [999 at macro-stdexten:1] Set("SIP/op-1-0902f218",
>>>>> "opt=m") in new stack
>>>>> -- Executing [999 at macro-stdexten:2] BackGround("SIP/op-1-0902f218",
>>>>> "transfer") in new stack
>>>>> -- <SIP/op-1-0902f218> Playing 'transfer' (language 'en')
>>>>> -- Executing [999 at macro-stdexten:3] Goto("SIP/op-1-0902f218",
>>>>> "s|dial") in new stack
>>>>> -- Goto (macro-stdexten,s,3)
>>>>> -- Executing [s at macro-stdexten:3] Dial("SIP/op-1-0902f218",
>>>>> "SIP/213|20|m") in new stack
>>>>> -- Called 213
>>>>> -- Music class default requested but no musiconhold loaded.
>>>>> -- AGI Script Executing Application: (Dial) Options: (SIP/201|30)
>>>>> -- SIP/213-090126f8 is ringing
>>>>> asterisk*CLI>
>>>>> Disconnected from Asterisk server
>>>>> Executing last minute cleanups
>>>>> Asterisk cleanly ending (0).
>>>>>
>>>>> --
>>>>> Josiah Bryan
>>>>> IT Manager
>>>>> Productive Concepts, Inc.
>>>>> jbryan at productiveconcepts.com
>>>>> (765) 964-6009, ext. 224
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>>>
>>>>> AstriCon 2008 - September 22 - 25 Phoenix, Arizona
>>>>> Register Now: http://www.astricon.net
>>>>>
>>>>> asterisk-users mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>>>>
>>>>
>>> --
>>> Josiah Bryan
>>> IT Manager
>>> Productive Concepts, Inc.
>>> jbryan at productiveconcepts.com
>>> (765) 964-6009, ext. 224
>>>
>>>
>>> _______________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> AstriCon 2008 - September 22 - 25 Phoenix, Arizona
>>> Register Now: http://www.astricon.net
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>>
>>
>>
>
--
Josiah Bryan
IT Manager
Productive Concepts, Inc.
jbryan at productiveconcepts.com
(765) 964-6009, ext. 224
More information about the asterisk-users
mailing list