Summary:ASTERISK-06766: app_queue state change failing - loop/deadlock
Reporter:richardhh (richardhh)Labels:
Date Opened:2006-04-12 17:46:15Date Closed:2006-05-03 09:47:39
Versions:Frequency of
Description:Sorry for my english, i am german.
Happens randomly.

We handle ~2000 calls per day on our Asterisk, running on 3GHz pentium 4, 1 GB RAM, Kernel 2.4.27 (no highmem kernel tho).

After 3-5 days the CLI loops in a message:
app_queue:519 state change_queue: Failed to creat update thread!

We use (dialplan) a lot of dynamic agents, using AddQueueMember and RemoveQueueMember from dialplan.

Not sure what else info you need.
Feel free to request anything helpinh you, i am glad to provide any needed additional info.


Im not updating immediatly to every new version since our server is production and i dont want to experience bugs in a production environment, so i always wait a bit with new versions.
Comments:By: richardhh (richardhh) 2006-04-13 01:54:22

Continued in similar bugreport:

By: BJ Weschke (bweschke) 2006-04-19 10:38:50

RichardHH: are you still having this issue? Can you please let me know what you get when you do a "show version" of Asterisk on the CLI? I'll give you a patch that should allow us to gather some more information as to what's really going on w/o affecting your production system.

By: richardhh (richardhh) 2006-04-20 09:52:33

Heya !

I continued in the other bug, sorry for the delay.

The problem is, i cant afford in ANY way to have our production PBX going down, thats why i have a daily cron running now (shutdown -r now) at 06:01am.

So unfortunatly, i cant say if the bug is still present, lol.

I updated to 1.2.7 the other night, shortly before was released.
1.2.7 is the now running version here.

Well, i guess i cant really help tracking it down anymore due to my cron job :(

Im so sorry, but the PBX being up is the absolute #1 prio here.

If i can provide anymore help without "disturbing" our system, i'd gladly help.

By: Serge Vecher (serge-v) 2006-05-03 09:47:39

RichardHH: as I've suggested in 6153, if you can reproduce this issue on a backup or test server, please a get backtrace from 1.2.7-1 or later built with 'make dont-optimize'