It has nothing to do with not being unloaded; I've seen the wctdm driver fail to detect modules correctly. Run it again and it works just fine. Some kind of minor tweak is in order, I believe.
As an interim solution, your asterisk starup script should try to unload any modules and reload them upon asterisk failure... preferably in a loop:
while(1) { unload modules sleep 1 load modules start asterisk sleep 5 }
I imagine at this point in time your startup script either does not loop, or it doesn't try to unload/load the modules inside the loop.
While I like the idea (and will look into it -- might need a wait, etc), as I said in original post, unloading and reloading did not fix the problem. It took a clean shutdown (unload and restart) to fix the problem.
So regardless of why the card has failed, I would like to discuss making chan_zap fail gracefully. For example if you have a Dial(Zap/3/${NUMBER}, and Zap/3 does not exist, asterisk will spit a warning (not fail to startup). However if you have that channel => 3 in zapata.conf, chan_zap will fail and prevent asterisk from starting.
I would think that everyone would prefer asterisk to start and have parts of the dialplan fail, rather than have asterisk not load at all.
As I said, I have not checked the behavior of cvs-head, I just wanted to discuss making asterisk more resilient.
Thanks for the tip and I will look into it.
Jeb -- Jeb Campbell [EMAIL PROTECTED] _______________________________________________ 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
