Discussion:
[asterisk-users] Asterisk Crash
Josiah Bryan
2008-09-03 14:14:04 UTC
Permalink
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 [***@playground:1] Macro("SIP/op-1-0902f218",
"stdexten|213|SIP/213") in new stack
-- Executing [***@macro-stdexten:1] GotoIf("SIP/op-1-0902f218",
"1?999|1") in new stack
-- Goto (macro-stdexten,999,1)
-- Executing [***@macro-stdexten:1] Set("SIP/op-1-0902f218",
"opt=m") in new stack
-- Executing [***@macro-stdexten:2] BackGround("SIP/op-1-0902f218",
"transfer") in new stack
-- <SIP/op-1-0902f218> Playing 'transfer' (language 'en')
-- Executing [***@macro-stdexten:3] Goto("SIP/op-1-0902f218",
"s|dial") in new stack
-- Goto (macro-stdexten,s,3)
-- Executing [***@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.
***@productiveconcepts.com
(765) 964-6009, ext. 224
Andrew Latham
2008-09-03 15:33:08 UTC
Permalink
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
Post by Josiah Bryan
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.
"stdexten|213|SIP/213") in new stack
"1?999|1") in new stack
-- Goto (macro-stdexten,999,1)
"opt=m") in new stack
"transfer") in new stack
-- <SIP/op-1-0902f218> Playing 'transfer' (language 'en')
"s|dial") in new stack
-- Goto (macro-stdexten,s,3)
"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.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Andrew "lathama" Latham
Principal
TuxTone Inc.
http://TuxTone.com
***@TuxTone.com
Josiah Bryan
2008-09-03 17:06:51 UTC
Permalink
"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
Post by Andrew Latham
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
Post by Josiah Bryan
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.)
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.
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
Linux asterisk.productiveconcepts.com 2.6.9-1.667 #1 Tue Nov 2 14:41:25
EST 2004 i686 i686 i386 GNU/Linux
total used free shared buffers cached
Mem: 255652 253416 2236 0 1380 81220
-/+ buffers/cache: 170816 84836
Swap: 524280 8340 515940
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
Post by Andrew Latham
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
Post by Josiah Bryan
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.
"stdexten|213|SIP/213") in new stack
"1?999|1") in new stack
-- Goto (macro-stdexten,999,1)
"opt=m") in new stack
"transfer") in new stack
-- <SIP/op-1-0902f218> Playing 'transfer' (language 'en')
"s|dial") in new stack
-- Goto (macro-stdexten,s,3)
"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.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Josiah Bryan
IT Manager
Productive Concepts, Inc.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Josiah Bryan
IT Manager
Productive Concepts, Inc.
***@productiveconcepts.com
(765) 964-6009, ext. 224
Josiah Bryan
2008-09-03 20:43:24 UTC
Permalink
Well, at the time I wrote the AGI, fewestcalls wasn't an option (or at
least, I couldn't find it through googling or on the voip-info wiki).

Since then, the script has been in production use for 3+ years and I
havn't bothered to go back rework the dialplan. Sorry for the trouble
though.

However, it still begs the question, why does Dial seem to "fall
through" like that after the operator transfers the call? Is that
expected/designed behavior? If yes, Has that changed since the 1.0 days
of asterisk? If yes, Is there a switch that can turn that off?

Thanks for your patience with all these questions.

Regards,
-josiah
Post by Andrew Latham
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
Post by Josiah Bryan
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
Post by Josiah Bryan
"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
Post by Andrew Latham
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
Post by Josiah Bryan
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.)
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.
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
Linux asterisk.productiveconcepts.com 2.6.9-1.667 #1 Tue Nov 2 14:41:25
EST 2004 i686 i686 i386 GNU/Linux
total used free shared buffers cached
Mem: 255652 253416 2236 0 1380 81220
-/+ buffers/cache: 170816 84836
Swap: 524280 8340 515940
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
Post by Andrew Latham
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
Post by Josiah Bryan
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.
"stdexten|213|SIP/213") in new stack
"1?999|1") in new stack
-- Goto (macro-stdexten,999,1)
"opt=m") in new stack
"transfer") in new stack
-- <SIP/op-1-0902f218> Playing 'transfer' (language 'en')
"s|dial") in new stack
-- Goto (macro-stdexten,s,3)
"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.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Josiah Bryan
IT Manager
Productive Concepts, Inc.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Josiah Bryan
IT Manager
Productive Concepts, Inc.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Josiah Bryan
IT Manager
Productive Concepts, Inc.
***@productiveconcepts.com
(765) 964-6009, ext. 224
Josiah Bryan
2008-09-03 20:04:16 UTC
Permalink
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
Post by Josiah Bryan
"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
Post by Andrew Latham
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
Post by Josiah Bryan
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.)
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.
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
Linux asterisk.productiveconcepts.com 2.6.9-1.667 #1 Tue Nov 2 14:41:25
EST 2004 i686 i686 i386 GNU/Linux
total used free shared buffers cached
Mem: 255652 253416 2236 0 1380 81220
-/+ buffers/cache: 170816 84836
Swap: 524280 8340 515940
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
Post by Andrew Latham
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
Post by Josiah Bryan
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.
"stdexten|213|SIP/213") in new stack
"1?999|1") in new stack
-- Goto (macro-stdexten,999,1)
"opt=m") in new stack
"transfer") in new stack
-- <SIP/op-1-0902f218> Playing 'transfer' (language 'en')
"s|dial") in new stack
-- Goto (macro-stdexten,s,3)
"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.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Josiah Bryan
IT Manager
Productive Concepts, Inc.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Josiah Bryan
IT Manager
Productive Concepts, Inc.
***@productiveconcepts.com
(765) 964-6009, ext. 224
Andrew Latham
2008-09-03 20:27:57 UTC
Permalink
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
Post by Josiah Bryan
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
Post by Josiah Bryan
"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
Post by Andrew Latham
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
Post by Josiah Bryan
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.)
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.
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
Linux asterisk.productiveconcepts.com 2.6.9-1.667 #1 Tue Nov 2 14:41:25
EST 2004 i686 i686 i386 GNU/Linux
total used free shared buffers cached
Mem: 255652 253416 2236 0 1380 81220
-/+ buffers/cache: 170816 84836
Swap: 524280 8340 515940
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
Post by Andrew Latham
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
Post by Josiah Bryan
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.
"stdexten|213|SIP/213") in new stack
"1?999|1") in new stack
-- Goto (macro-stdexten,999,1)
"opt=m") in new stack
"transfer") in new stack
-- <SIP/op-1-0902f218> Playing 'transfer' (language 'en')
"s|dial") in new stack
-- Goto (macro-stdexten,s,3)
"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.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Josiah Bryan
IT Manager
Productive Concepts, Inc.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Josiah Bryan
IT Manager
Productive Concepts, Inc.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Andrew "lathama" Latham
Principal
TuxTone Inc.
http://TuxTone.com
***@TuxTone.com
Josiah Bryan
2008-09-03 15:43:50 UTC
Permalink
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:

[***@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

[***@asterisk asterisk]# free
total used free shared buffers cached
Mem: 255652 253416 2236 0 1380 81220
-/+ buffers/cache: 170816 84836
Swap: 524280 8340 515940

[***@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
Post by Andrew Latham
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
Post by Josiah Bryan
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.
"stdexten|213|SIP/213") in new stack
"1?999|1") in new stack
-- Goto (macro-stdexten,999,1)
"opt=m") in new stack
"transfer") in new stack
-- <SIP/op-1-0902f218> Playing 'transfer' (language 'en')
"s|dial") in new stack
-- Goto (macro-stdexten,s,3)
"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.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Josiah Bryan
IT Manager
Productive Concepts, Inc.
***@productiveconcepts.com
(765) 964-6009, ext. 224
Andrew Latham
2008-09-03 16:11:58 UTC
Permalink
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
Post by Josiah Bryan
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.)
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.
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
Linux asterisk.productiveconcepts.com 2.6.9-1.667 #1 Tue Nov 2 14:41:25
EST 2004 i686 i686 i386 GNU/Linux
total used free shared buffers cached
Mem: 255652 253416 2236 0 1380 81220
-/+ buffers/cache: 170816 84836
Swap: 524280 8340 515940
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
Post by Andrew Latham
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
Post by Josiah Bryan
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.
"stdexten|213|SIP/213") in new stack
"1?999|1") in new stack
-- Goto (macro-stdexten,999,1)
"opt=m") in new stack
"transfer") in new stack
-- <SIP/op-1-0902f218> Playing 'transfer' (language 'en')
"s|dial") in new stack
-- Goto (macro-stdexten,s,3)
"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.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Josiah Bryan
IT Manager
Productive Concepts, Inc.
(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
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Andrew "lathama" Latham
Principal
TuxTone Inc.
http://TuxTone.com
***@TuxTone.com
Tony Mountifield
2008-09-05 14:41:14 UTC
Permalink
Post by Josiah Bryan
Well, at the time I wrote the AGI, fewestcalls wasn't an option (or at
least, I couldn't find it through googling or on the voip-info wiki).
Since then, the script has been in production use for 3+ years and I
havn't bothered to go back rework the dialplan. Sorry for the trouble
though.
However, it still begs the question, why does Dial seem to "fall
through" like that after the operator transfers the call? Is that
expected/designed behavior? If yes, Has that changed since the 1.0 days
of asterisk? If yes, Is there a switch that can turn that off?
Thanks for your patience with all these questions.
You might want to look at the j option to Dial.

In 1.0 days, a failed Dial would jump to priority n+101. Before 1.2 this
got changed so it didn't. Instead you were supposed to check ${DIALSTATUS}.
However, for compatibility, the old jump behaviour can be reinstated with
the j option.

The above applies when Dial is called from the dialplan. I have no idea
whether it applied when Dial was called from EXEC in AGI, but it's worth
a try.

Cheers
Tony
--
Tony Mountifield
Work: ***@softins.co.uk - http://www.softins.co.uk
Play: ***@mountifield.org - http://tony.mountifield.org
Loading...