Re: [asterisk-users] Avoiding deadlock
Hi Moises, Thanks for your opinion. However I still wouldn't want to agree that reducing debug logging is a solution. Let me explain why, we are driving Asterisk using AMI and verbose logging is simply not enough to investigate issues that arises with our software or Asterisk itself. Also we are getting valuable information from the debug logs in order to verify activities in our own logs. Printing Avoiding deadlock message 12000 times in the logs makes system less efficient and causes performance degradation due to massive I/O activity. Would you say this should be ignored too? I'm not implying that Avoiding deadlock is the problem here, maybe its Asterisk debug logging? Regards, Vilius. On 18 November 2010 03:35, Moises Silva moises.si...@gmail.com wrote: On Wed, Nov 17, 2010 at 9:56 AM, Vilius Adamkavicius vilius.adamkavic...@invade.net wrote: Hi Chad, Thanks for your suggestions. However I believe decreasing logging, its just like closing your eyes and ignoring what happening behind you, the problem is still there. Also decreased logging will prevent from troubleshooting any other problems in the future. Would you happen to know any potential causes for this message? The problem is you were just told by a Digium engineer who knows the code from many years back that is a debug message and there is nothing to worry about and you insist in believing this is a problem. If you want to know what the message means and why you should not worry you must understand what a lock is, what lock contention is and what a deadlock is. Moises Silva Senior Software Engineer Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON L3R 9R6 Canada t. 1 905 474 1990 x128 | e. m...@sangoma.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Avoiding deadlock
For some reason we are seeing Avoiding deadlock for channel in our Asterisk logs, the logs are getting filled up with an amazing speed around 12000 lines a second, and all of them are Avoiding deadlock. What could be the potential reason for this to be happening? The Asterisk is used as auto dialler, therefore different channel types are involved SIP, DAHDI, Local's. [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' Asterisk: 1.4.33.1 DAHDI: dahdi-2.3.0.1-3 Regards, Vilius. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Avoiding deadlock
Hi Chad, Thanks for your suggestions. However I believe decreasing logging, its just like closing your eyes and ignoring what happening behind you, the problem is still there. Also decreased logging will prevent from troubleshooting any other problems in the future. Would you happen to know any potential causes for this message? Regards, Vilius. On 16 November 2010 20:13, Chad Wallace cwall...@lodgingcompany.com wrote: On Tue, 16 Nov 2010 14:08:45 + Vilius Adamkavicius vilius.adamkavic...@invade.net wrote: For some reason we are seeing Avoiding deadlock for channel in our Asterisk logs, the logs are getting filled up with an amazing speed around 12000 lines a second, and all of them are Avoiding deadlock. What could be the potential reason for this to be happening? The Asterisk is used as auto dialler, therefore different channel types are involved SIP, DAHDI, Local's. [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' Turn off debugging. On the asterisk CLI, run this command: core set debug 0 Also, check the command line in your init script, or however you run asterisk, and if there is a -d option, remove it. Otherwise, debugging will come back on next time you restart asterisk. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Vilius Adamkavicius InVADE Technical Support 3 Berkeley Crescent, Bristol United Kingdom BS8 1HA Company Registration Number: 3660482 Registered in England and Wales this email, and any attachment, is intended only for the attention of the addressee. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please destroy all copies and inform the sender by return email. If you have received this email in error, please return it to the sender and highlight the error. We accept no legal liability for the content of the message. Any opinions or views presented are solely the responsibility of the author and do not necessarily represent those of InVADE. We cannot guarantee that this message has not been modified in transit, and this message should not be viewed as contractually binding. Although we have taken reasonable steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. international phone number +44(0) 117 33 555 00 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Avoiding deadlock
On Wed, Nov 17, 2010 at 9:56 AM, Vilius Adamkavicius vilius.adamkavic...@invade.net wrote: Hi Chad, Thanks for your suggestions. However I believe decreasing logging, its just like closing your eyes and ignoring what happening behind you, the problem is still there. Also decreased logging will prevent from troubleshooting any other problems in the future. Would you happen to know any potential causes for this message? The problem is you were just told by a Digium engineer who knows the code from many years back that is a debug message and there is nothing to worry about and you insist in believing this is a problem. If you want to know what the message means and why you should not worry you must understand what a lock is, what lock contention is and what a deadlock is. Moises Silva Senior Software Engineer Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON L3R 9R6 Canada t. 1 905 474 1990 x128 | e. m...@sangoma.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Avoiding deadlock
On Tue, 16 Nov 2010 14:08:45 + Vilius Adamkavicius vilius.adamkavic...@invade.net wrote: For some reason we are seeing Avoiding deadlock for channel in our Asterisk logs, the logs are getting filled up with an amazing speed around 12000 lines a second, and all of them are Avoiding deadlock. What could be the potential reason for this to be happening? The Asterisk is used as auto dialler, therefore different channel types are involved SIP, DAHDI, Local's. [Nov 15 14:20:01] DEBUG[21740] channel.c: Avoiding deadlock for channel '0x9f17c88' Turn off debugging. On the asterisk CLI, run this command: core set debug 0 Also, check the command line in your init script, or however you run asterisk, and if there is a -d option, remove it. Otherwise, debugging will come back on next time you restart asterisk. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Avoiding deadlock-line drop problem
Hi,all Randomly my line drops and when I look in message log file I always see the following notice: NOTICE[14491] chan_zap.c : avoiding deadlock… The situation appears with no obvious reason, the CLI shows nothing more than the zaptel channel hanging up. I have a Asterisk 1.2.10 and Zaptel 1.2.7 installation on a MSI motherboard with intel chipset 915G.The machine is equiped with a TDM40B and a TDM22B. Can somebody help with this mess? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] Avoiding deadlock... Problem
Hi I have 3FXO trunks called ZAP-25,ZAP-26 and ZAP-28 and T1 Channnel bank I get this deadlock problem when 2 incoming call from FXO(Here ZAP-28 and then ZAP-26) wants to dial same channel (Here ZAP-1). In this senario ZAP-1 first answer ZAP-28 and thne ZAP-26 wants to call ZAP-1 but it time out and goto voicemail after that ZAP-1 try to reach ZAP-26 call by puting ZAP-28 on HOLD During this period this this Notice is generates. And sometimes because of this Lines goes to dead. and need to restart asterisk. Please help me. Here is my LOG --- Apr 25 16:39:53 VERBOSE[3514] logger.c: -- Starting simple switch on 'Zap/28-1' Apr 25 16:39:54 VERBOSE[3514] logger.c: -- Executing Set(Zap/28-1, FROM=s) in new stack Apr 25 16:39:54 VERBOSE[3514] logger.c: -- Executing Goto(Zap/28-1, incoming-ivr|s|1) in new stack Apr 25 16:39:54 VERBOSE[3514] logger.c: -- Goto (incoming-ivr,s,1) Apr 25 16:39:54 VERBOSE[3514] logger.c: -- Executing GotoIf(Zap/28-1, 1?3) in new stack Apr 25 16:39:54 VERBOSE[3514] logger.c: -- Goto (incoming-ivr,s,3) Apr 25 16:39:54 VERBOSE[3514] logger.c: -- Executing Answer(Zap/28-1, ) in new stack Apr 25 16:39:54 VERBOSE[3514] logger.c: -- Executing Set(Zap/28-1, TIMEOUT(digit)=5) in new stack Apr 25 16:39:54 VERBOSE[3514] logger.c: -- Digit timeout set to 5 Apr 25 16:39:54 VERBOSE[3514] logger.c: -- Executing Set(Zap/28-1, TIMEOUT(response)=7) in new stack Apr 25 16:39:54 VERBOSE[3514] logger.c: -- Response timeout set to 7 Apr 25 16:39:54 VERBOSE[3514] logger.c: -- Executing BackGround(Zap/28-1, silence/1) in new stack Apr 25 16:39:54 VERBOSE[3514] logger.c: -- Playing 'silence/1' (language 'en') Apr 25 16:39:55 VERBOSE[3514] logger.c: -- Executing BackGround(Zap/28-1, maingreeting) in new stack Apr 25 16:39:55 VERBOSE[3514] logger.c: -- Playing 'maingreeting' (language 'en') Apr 25 16:40:03 VERBOSE[3530] logger.c: -- Starting simple switch on 'Zap/26-1' Apr 25 16:40:04 VERBOSE[3530] logger.c: -- Executing Set(Zap/26-1, FROM=s) in new stack Apr 25 16:40:04 VERBOSE[3530] logger.c: -- Executing Goto(Zap/26-1, incoming-ivr|s|1) in new stack Apr 25 16:40:04 VERBOSE[3530] logger.c: -- Goto (incoming-ivr,s,1) Apr 25 16:40:04 VERBOSE[3530] logger.c: -- Executing GotoIf(Zap/26-1, 1?3) in new stack Apr 25 16:40:04 VERBOSE[3530] logger.c: -- Goto (incoming-ivr,s,3) Apr 25 16:40:04 VERBOSE[3530] logger.c: -- Executing Answer(Zap/26-1, ) in new stack Apr 25 16:40:04 VERBOSE[3530] logger.c: -- Executing Set(Zap/26-1, TIMEOUT(digit)=5) in new stack Apr 25 16:40:04 VERBOSE[3530] logger.c: -- Digit timeout set to 5 Apr 25 16:40:04 VERBOSE[3530] logger.c: -- Executing Set(Zap/26-1, TIMEOUT(response)=7) in new stack Apr 25 16:40:04 VERBOSE[3530] logger.c: -- Response timeout set to 7 Apr 25 16:40:04 VERBOSE[3530] logger.c: -- Executing BackGround(Zap/26-1, silence/1) in new stack Apr 25 16:40:04 VERBOSE[3530] logger.c: -- Playing 'silence/1' (language 'en') Apr 25 16:40:05 VERBOSE[3530] logger.c: -- Executing BackGround(Zap/26-1, maingreeting) in new stack Apr 25 16:40:05 VERBOSE[3530] logger.c: -- Playing 'maingreeting' (language 'en') Apr 25 16:40:06 VERBOSE[3514] logger.c: == CDR updated on Zap/28-1 Apr 25 16:40:06 VERBOSE[3514] logger.c: -- Executing Macro(Zap/28-1, dial|ZAP/1|101) in new stack Apr 25 16:40:06 VERBOSE[3514] logger.c: -- Executing Dial(Zap/28-1, ZAP/1|15|) in new stack Apr 25 16:40:06 VERBOSE[3514] logger.c: -- Called 1 Apr 25 16:40:06 VERBOSE[3514] logger.c: -- Zap/1-1 is ringing Apr 25 16:40:08 VERBOSE[3514] logger.c: -- Zap/1-1 is ringing Apr 25 16:40:12 VERBOSE[3514] logger.c: -- Zap/1-1 answered Zap/28-1 Apr 25 16:40:12 VERBOSE[3514] logger.c: -- Attempting native bridge of Zap/28-1 and Zap/1-1 Apr 25 16:40:18 VERBOSE[3530] logger.c: == CDR updated on Zap/26-1 Apr 25 16:40:18 VERBOSE[3530] logger.c: -- Executing Macro(Zap/26-1, dial|ZAP/1|101) in new stack Apr 25 16:40:18 VERBOSE[3530] logger.c: -- Executing Dial(Zap/26-1, ZAP/1|15|) in new stack Apr 25 16:40:18 VERBOSE[3530] logger.c: -- Called 1 Apr 25 16:40:19 VERBOSE[3530] logger.c: -- Zap/1-2 is ringing Apr 25 16:40:19 VERBOSE[3514] logger.c: -- CPE does not support Call Waiting Caller*ID. Apr 25 16:40:34 VERBOSE[3530] logger.c: -- Nobody picked up in 15000 ms Apr 25 16:40:34 VERBOSE[3530] logger.c: -- Hungup 'Zap/1-2' Apr 25 16:40:34 VERBOSE[3530] logger.c: -- Executing GotoIf(Zap/26-1, 0?s-NOANSWER|1) in new stack Apr 25 16:40:34 VERBOSE[3530] logger.c: -- Executing Macro(Zap/26-1, vm|101|NOANSWER) in new stack Apr 25 16:40:34 VERBOSE[3530] logger.c: -- Executing Goto(Zap/26-1, s-NOANSWER|1) in new stack Apr 25 16:40:34 VERBOSE[3530] logger.c: -- Goto (macro-vm,s-NOANSWER,1) Apr 25 16:40:34 VERBOSE[3530] logger.c: -- Executing VoiceMail(Zap/26-1, u101) in new stack Apr 25 16:40:34 VERBOSE[3530] logger.c: -- Playing
[Asterisk-Users] Avoiding deadlock
Please could somebody explane me why this happens. I could receive calls but could not orginate calls. Oct 15 17:51:10 DEBUG[777237]: Avoiding deadlock for 'SIP/1112-7baf'Oct 15 17:51:10 DEBUG[777237]: Avoiding deadlock for 'SIP/1112-7baf'Oct 15 17:51:10 DEBUG[777237]: Avoiding deadlock for 'SIP/1112-7baf'Oct 15 17:51:10 DEBUG[777237]: Avoiding deadlock for 'SIP/1112-7baf'Oct 15 17:51:10 DEBUG[777237]: Avoiding deadlock for 'SIP/1112-7baf'Oct 15 17:51:10 DEBUG[777237]: Avoiding deadlock for 'SIP/1112-7baf'Oct 15 17:51:10 DEBUG[777237]: Avoiding deadlock for 'SIP/1112-7baf'Oct 15 17:51:10 DEBUG[777237]: Avoiding deadlock for 'SIP/1112-7baf'Oct 15 17:51:10 DEBUG[777237]: Avoiding deadlock for 'SIP/1112-7baf'Oct 15 17:51:10 DEBUG[777237]: Avoiding deadlock for 'SIP/1112-7baf'Oct 15 17:51:10 WARNING[777237]: Avoided deadlock for 'SIP/1112-7baf', 10 retries! Regards, Bartosz ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
