Summary:	ASTERISK-04024: Asterisk stop respond and full log with "Failed to grab lock, trying again..."
Reporter:	apignard (apignard)	Labels:
Date Opened:	2005-05-01 21:58:11	Date Closed:	2011-06-07 14:10:13
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Asterisk stop responding around 4 to 10 time a day and fill full log with "Failed to grab lock, trying again..." With CVS HEAD from mid January no problem at all. No crash since mid January. (I would like upgrade for get last libpri code due of problem with a new telco) Problem is totally random. Just wait some hours/half a day and it's happen. Seems it's appear mostly after a call. verbosity and debug are set to 30 I have notice that's several time i have this : cdr_mysql: inserting a CDR record. Failed to grab lock, trying again... Failed to grab lock, trying again... I have disable cdr_mysql and i have more than half of crash for the last active day (friday) I still have a custom cdr_mysql running, and i can't disable it since it's our billing system. I have also notice many "channel.c: Avoiding deadlock for" that's i haven't in CVS HEAD of january.
Comments:	By: Kevin P. Fleming (kpfleming) 2005-05-01 22:04:33 So you're saying that you disable one cdr_mysql and the frequency of the crashes was reduced, but you're unwilling to disable the other one? Since there are no other reports of this sort of problem, it's very likely that your custom CDR module is the source of the trouble, and we won't be able to help you solve it without at least seeing the source code for it. By: Kevin P. Fleming (kpfleming) 2005-05-01 22:05:31 Changing to 'minor' because there appears to be a workaround for the problem (don't use the custom CDR module). By: apignard (apignard) 2005-05-01 22:28:38 If i disable my cdr_mysql (custom). What do you prefer : 1) no cdr 2) cdr_cvs 3) cdr_mysql Thanks modifié le : 05-01-05 22:31 By: Kevin P. Fleming (kpfleming) 2005-05-01 23:01:38 The most important thing for debugging purposes is that you are running a completely "stock" version of Asterisk, without additional modules or modified modules. That way we can try to duplicate your problem, or at least help you generate debugging information so we figure out what is going on. If the problem is not reproducable without your custom/modified modules, then it will be difficult for us to help you. By: Abhishek Tiwari (abhi) 2005-05-02 01:54:19 I had a lot of Avoided Initial deadlock messages when running good load. Tracing found that it was all when the chan lock was aquired in ast_hangup and putting more logs revealed that the cdr part was taking a few seconds sometimes. Moving the cdr part after unlocking and before freeing in ast_hanngup has solved this and I dont get any more of these Avoded deadlock messages, though I am not sure of the implications of moving the cdr part outsinde the lock. By: apignard (apignard) 2005-05-02 02:02:09 I have also notice this. I have many Avoided deadlock when CDR/Mysql is running. On the next crash i will have no CDR engine and see if asterisk still stable or not. I have read all cvs since january and i don't see much modification except on realtime that's can cause this problem. By: apignard (apignard) 2005-05-02 12:03:22 Ok, here is some more test : custom_cdr_mysql : running without crash for 4 hours (deadlock) cdr_addons_mysql : running for 30 mins and crash (no more SIP stack, no deadlock message,  manager still working and vty still working) No problem without cdr_addons_mysql or customer cdr (running for 5 hours the busy one) Maybe a bug in cdr_addons_mysql (or incompatibility with new source). NO CRASH on the same server with cdr_addons or custom_cdr with January CVS By: Clod Patry (junky) 2005-05-24 18:13:28 Where are we with all that? /Housekeeping By: apignard (apignard) 2005-05-24 18:30:35 I have upgrade several time to HEAD and seems the problem gone away with one update. Seems stable now. I have just an issue with IAX & REALTIME but i will report on another bugtrack when i have enough information on the cause of the bug (totally new bug, easy reproduce on busy server) By: twisted (twisted) 2005-05-25 00:16:36 reporter states bug is no longer present.