[Asterisk-Users] asterisk dies while making calls

[Steven Critchfield]

On Fri, 2004-01-02 at 09:27, Asterisk List wrote:
> Hello:
> 
> It has happened while I was making 1000 outgoing calls, at a sustained rate 
> of 2 calls per second.
> Asterisk makes a SIP call to a CISCO router and this router is connected to 
> the PSTN line.
> 
> While putting files in the outgoig folder, I noticed that the files remained 
> there and the calls have stopped. Looking for the asterisk process, it was 
> gone.

> In /var/log/asterisk/messages file I find these lines:
> Jan  2 14:10:16 NOTICE[99500051]: File pbx_spool.c, Line 199 
> (attempt_thread): Call failed to go through, reason 5
> Jan  2 14:10:17 NOTICE[99483665]: File pbx_spool.c, Line 199 
> (attempt_thread): Call failed to go through, reason 5
> Jan  2 14:10:17 NOTICE[99532821]: File pbx_spool.c, Line 199 
> (attempt_thread): Call failed to go through, reason 5
> Jan  2 14:10:18 NOTICE[99516436]: File pbx_spool.c, Line 199 
> (attempt_thread): Call failed to go through, reason 5
> Jan  2 14:10:18 NOTICE[99565587]: File pbx_spool.c, Line 199 
> (attempt_thread): Call failed to go through, reason 5
> Jan  2 14:10:19 NOTICE[99549201]: File pbx_spool.c, Line 199 
> (attempt_thread): Call failed to go through, reason 5
> Jan  2 14:10:19 NOTICE[99581972]: File pbx_spool.c, Line 199 
> (attempt_thread): Call failed to go through, reason 5
> Jan  2 14:10:20 NOTICE[99598357]: File pbx_spool.c, Line 199 
> (attempt_thread): Call failed to go through, reason 5
> Jan  2 14:10:20 WARNING[81926]: File chan_sip.c, Line 450 (retrans_pkt): 
> Maximum retries exceeded on call 
> 70d2446e14d7e0f609531f5d671b86b5 at 192.168.200.102 for seqno 102 (Request)
> Jan  2 14:10:20 NOTICE[81926]: File sched.c, Line 209 (sched_settime): 
> Request to schedule in the past?!?!
> 
> This was the last line, asterisk died and the process dissapeared.
> What happened? Where can I find more asterisk log files to discover it?

The messages above appear to be failed threads. It seems you hit a limit
in your kernel or thread library for running processes. If you had been
on the end of one of the calls their towards the end, you might have
noticed a severe call quality drop as each of these processes can only
use a small fraction of the CPU time, and I bet you started to starve
each one for enough time to do any useful work. 

If you so wish to try that again, maybe you should have a window open
watching top as asterisk nears that point to see exactly how many
running processes there are at the time. 

Also as a general rule of thumb, if you experience a crash and are able
to reproduce it, make sure you have the ability to drop a core file. You
usually do this by running "ulimit -c unlimited", and then moving to a
directory that can handle a couple meg file when the failure occurs.
Then you run the application like normal and proceed to cause the
failure. You will then be left with the memory from the application in a
file at the point it failed. This is useful to then use gdb on the file
to determine what it was doing at the time of failure. Usually a simple
back trace is enough to get started, and a back trace is printed using
the command bt from within gdb. 
-- 
Steven Critchfield  <critch at basesys.com>