asterisk users - Apr 2005 - chan_zap graceful failure

I was wondering if anyone is working on graceful failure for chan_zap?

Let me explain the situation.  We are using a T100P and TDM400P (4 FXS 
for fax).  There was a major power outage and asterisk went down after 
the UPS (not a graceful shutdown -- my fault, no apcupsd running).

As soon as power came back, the server started.  However when it loaded 
wcfxs, port 3 on the card failed the tests (I assume from the module not 
being unloaded before power off).  Because this one port failed the 
test, chan_zap failed to load and asterisk will not start.

An unload and load of modules would not fix it.  I had to unload and 
restart (a clean restart).

While the unclean shutdown can be controlled in the future, I have had 
ports go bad and when they do asterisk will not start until the 
offending lines are removed from zapata.conf.  This is not a very 
resilient solution (especially if you are not on site).  I would much 
prefer for asterisk to keep running with what it has got.

I will be looking into the code (and this might be fixed in cvs-head), 
but I would like to start a discussion on this first.

Thanks,

Jeb
-- 
Jeb Campbell
jebc@c4solutions.net

On April 29, 2005 11:22 am, Jeb Campbell wrote:
> As soon as power came back, the server started.  However when it loaded
> wcfxs, port 3 on the card failed the tests (I assume from the module not
> being unloaded before power off).  Because this one port failed the
> test, chan_zap failed to load and asterisk will not start.
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.
> While the unclean shutdown can be controlled in the future, I have had
> ports go bad and when they do asterisk will not start until the
> offending lines are removed from zapata.conf.  This is not a very
> resilient solution (especially if you are not on site).  I would much
> prefer for asterisk to keep running with what it has got.
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.

 -A.