Topic: Asterisk dropping out every so often

[David Harper]

Every so often, seemingly at random, SARK stops processing, and we cannot call in our out, both over the TDM card and over the VOIP (PennyTel).

The only fix seems to be to stop and then restart sail. In addition, sometimes we have to issue a "load chan_zap.so" command from the Asterisk CLI.

Very weird. Note that this is SAIL 688. I am waiting for SAIL 715 to come out before upgrading to the 7xx series.

[SARK devs]

What hardware are you using?

Have you searched the Asterisk BB's?


S

[David Harper]

It's a genuine Digium TDM413E. 3x FXS, 1x FXO.

I'm unsure what I would search for. It's unclear what exactly is causing the issue. The fact that it is losing its configuration suggested a SAIL issue to me, though I could be wrong.

[SARK devs]

We have no reported issues of freezing and we have recorded just under 2000 downloads.

When you say "losing configuration"  can you explain what you mean please?  The asterisk configs, as you know, are held on flat files in /etc/asterisk.  Which ones are being lost?

S

[David Harper]

Basically the analog channels disappear - also one of the handsets stops communicating altogether. The first time, I had to reload the chan_zap.so driver from the Asterisk console. The second time, I am unsure what happened.

It's unclear what exactly is going on, as there have been workpeople on site and lots of other stuff going on. I will see what happens tomorrow and report back.

[SARK devs]

Most references I can find are analogue card related. In preparation fro the next failure you might want to do the following:---
 
You might want to turn on full logging to see what is happening just before the freeze... In /etc/asterisk/logger, uncomment the line which reads

;full => notice,warning,error,debug,verbose

Also, when it freezes, capture the output from dmesg and publish the last few lines of dmesg and the last couple hundred lines of the full log (var/log/asterisk).

S

[David Harper]

Well this is an Analogue card, so that would make sense

Thanks for the info -- will grab the above information if/when this happens again.

[d6hq]

Did you ever get to the bottom of this. We have the same issue with two separate servers. For unknown reasons Asterisk simply stops running at some point overnight. Both have analogue cards (OpenVox) and both are connected to BT lines. The dropout time is varied. If we restart Sail then they come back onstream. A similar server without analogue card does not exhibit the same problem. Any pointers would be most welcome.

[David Harper]

A similar server without analogue card does not exhibit the same problem.

What is different about the "similar" server? The BT lines?

[d6hq]

Thanks David for the quick response. All three servers are Dell SC430 or 440. All running SME 7.3 with Sail 716 or above. 2 have analogue cards using BT lines. The third has no card and no connection to the PSTN. The 2 with cards show the drop out the one without does not.

[David Harper]

Is there anything in the logs that might help us? Particularly just before the line drops out?

[d6hq]

There is nothing in the Asterisk message log that gives any indication of the problem or indeed the exact time it occurs. We can only estimate when by the last successful call. At the moment we have bodged a fix by restarting all the underlying services on schedule first thing in the morning but this does not always sort out the problem fully as sometimes the system does not re-register one of the SIP trunklines.

[David Harper]

I'm not sure what to suggest to help narrow down what might be going wrong. Have you tried Selintra's earlier advice:

You might want to turn on full logging to see what is happening just before the freeze... In /etc/asterisk/logger, uncomment the line which reads

;full => notice,warning,error,debug,verbose

Also, when it freezes, capture the output from dmesg and publish the last few lines of dmesg and the last couple hundred lines of the full log (var/log/asterisk).

If the worst comes to the worst, perhaps you need to call in or out every few minutes after hours until Asterisk stops working, so you know what time frame we are looking at.

[d6hq]

We will need to do some more digging. I have just realised that there is another common factor between the two failing servers which is that their broadband lines are provided by BT Opensore. The one without the analogue card sits on a Zen line. Hence the problem may be nothing to do with the existence of the analogue card at all.

I shall report back in due course.

[d6hq]

Another strange thing about these servers is that the "State" indicators in both Trunklines and Extensions show the red cross even though all are registered. After a full reboot the indicators are Ok for a while and then are quickly replaced by the red cross. Clicking on the trunkline indicator gives the following message:

"Unable to connect to remote asterisk (does /var/run/asterisk/asterisk.ctl exist?)"

Have you seen this annoyance before ?