> We tend to find that on the rare occasions asterisk does decide to die, > it very often doesn't die completely.
Agreed. Need to also watch out for SIP deadlocks (asterisk is up, you can connect to the CLI, but it does not respond to any SIP traffic, or sip reload, or unload chan_sip, or restart). Sipsak via an external monitoring script works for us. On a timeout it first tries to gracefully stop asterisk, then it force kills it with kill -9, and the restarts it. That has proven successful in minimizing downtime. On the same machine, same binary, "same" traffic volume, sometime asterisk stays up for months (current record, 51 weeks!) and sometimes it will decide to die after couple days (current record, 6 times on the same day). A core dump doesn't reveal anything suspicious. It's not load related as crashed can happen at 3am when it's pretty quiet. I suspect it's due to network issues (dropped packets, etc) because sometimes just before the crash the console is full with __sip_destroy: Trying to destroy ... not found in dialog list?!?! messages. No, I have not upgraded to 1.4 yet. Still, I find it ironic that all this effort goes into fixing the symptom rather than the cause. But I'm not complaining... just don't have a better idea how to fix it. Luki _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
