[asterisk-users] Asterisk Crash
Andrew Latham
Andrew.Latham at TuxTone.com
Wed Sep 3 15:27:57 CDT 2008
I know many are thinking this but why don't you use a queue with
"fewestcalls" for the strategy?
On Wed, Sep 3, 2008 at 4:04 PM, Josiah Bryan
<jbryan at productiveconcepts.com> wrote:
> 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
>
>
> _______________________________________________
> -- 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
>
--
Andrew "lathama" Latham
Principal
TuxTone Inc.
http://TuxTone.com
Andrew.Latham at TuxTone.com
More information about the asterisk-users
mailing list