Summary:	ASTERISK-11167: Asterisk hanging whole system on certain configuration
Reporter:	dmartin (dmartin)	Labels:
Date Opened:	2008-01-06 13:18:10.000-0600	Date Closed:	2008-02-15 15:12:20.000-0600
Priority:	Blocker	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Hi, I'm using Asterisk 1.4.16.2 from Debian (Sid) on a Sparc machine. With this configuration, taken from extensions.conf, the whole system stops responding at all but ICMP pings (no ssh, telnet, nor serial console, and can't look for any debug). --------------- [services] exten => 298,1,Ringing exten => 298,2,Wait(8) exten => 298,3,Answer exten => 298,4,Monitor(wav,/pool/exports/recv/sw-${CALLERID(num)}-${EPOCH}) exten => 298,5,Playback(/var/lib/asterisk/sounds/custom/sn) exten => 298,6,Hangup exten => 55610,1,Dial(Local/298,90,tr) --------------- If I call 55610, the system hangs. If I call 298, it doesn't hang. If I comment the line Monitor(...) from 298 definition, the system doesn't hang either. In all cases when the system doesn't call, the extension works fine. If I change the extension 55610 to: exten => 55610,1,Goto(services,298,1) It works without a flaw, and no hangs. Maybe it's a thing of Local/* ? Or the Monitor() application ? Or the ${CALLERID(num)} usage on a mix of these ? That's why I clasiffied bug on General. I'm sure that if I apply limits to the proccess (ie, limit cpu time or proccesses), then the kernel would kill  Asterisk and come back to a usable state, but I won't do it for this report since the only fact that Asterisk hang a system should be sufficient to report this. ****** ADDITIONAL INFORMATION ****** Asterisk 1.4.16.2 running on Debian GNU/Linux(Sid) with latest 2.6 kernel from git, on a Sun Netra X1 (UltraSPARC-IIe 500MHz, 1024 MB RAM)
Comments:	By: Tzafrir Cohen (tzafrir) 2008-01-07 07:57:07.000-0600 For starters, run asterisk without the option -p, to make such loops non-fatal. In Debian: echo AST_REALTIME=no >>/etc/default/asterisk This should let you sort out the exact dialplan loop that occours there. I suspect that it is related to the 's' extension. The general problem of a dialplan loop hanging Asterisk if -p was used is at least partially solved in trunk using the canary process. By: Mark Michelson (mmichelson) 2008-01-07 11:07:33.000-0600 I believe the problem is that you need to have @services after Local/298 in your Dial() line for extension 55610, like this: exten => 55610,1,Dial(Local/298@services,90,tr) See if that fixes your issue. By: dmartin (dmartin) 2008-01-07 13:26:36.000-0600 Hi, Since by now the Debain Sid packages of Asterisk for Sparc are broken, I built the svn (trunk) version to test with the latest Asterisk. I will post the results here when I do the test. I didn't know about the -p parameter coul avoid this, thank you! But I _do_ need Asterisk to run realtime. For putnopvut, I already tested with @services, and crashed. The only way not to hang the system using Local/*, is commenting out the Monitor() command. By: Tzafrir Cohen (tzafrir) 2008-01-07 13:45:30.000-0600 Issues with the Debian packages should be reported to the Debian Bug Tracking System. Please use:  reportbug asterisk However in your case it apears to be some sort of dialplan loop. Unless you really mean that Asterisk crashes (and doesn't simply get into a loop). This is simple to test: 1. disable -p as shown above. Verify that by running 'ps ax | grep asterisk' and check that the option -p is not used. 2. Run asterisk -rvvv 3. Start your test. You should see a trace of the dialplan that Asterisk goes through. 4. If you rem-out the 'monitor' line, you will also not proceed to Playback and Hangup. By: dmartin (dmartin) 2008-01-08 13:14:45.000-0600 On current SVN trunk (as of 96988) it doesn't hang at all: it works perfect (both Local/298 and Local/298@services), no need for canary either. Can't test by now on 1.4 again but as soon as I can I will do some tests without the -p. By: Mark Michelson (mmichelson) 2008-02-06 14:33:24.000-0600 Ping. Any progress? By: Mark Michelson (mmichelson) 2008-02-15 15:12:19.000-0600 No feedback from reporter in over a month, and issue sounds as if it is resolved anyway. Closing.