<html><head><style type='text/css'>p { margin: 0; }</style><style type='text/css'>body { font-family: 'Times New Roman'; font-size: 12pt; color: #000000}</style></head><body>We've found the Trixbox 2.6 series to be quite unstable which is why we're still running 2.4 for those installations that require Trixbox.<br><br>Having someone tell you "your daemon crashing and restarting is normal" doesn't seem very bright. Wouldn't the proper path be to find out why it is crashing? I mean seriously, if the asterisk installation at *MY* house was crashing and restarting, who cares. But *YOURS*? Thats a different story...<br><br>You should really dive into your logs to see where the problem is coming from. /var/log/asterisk/full should have what you want but you'll need to do some heavy sifting as it contains very verbose output.<br><br>Also, post this on the Trixbox forums. I'm sure someone over there can lend a hand also.<br><br>Good luck!<br><br>Tim Nelson<br>Systems/Network Support<br>Rockbochs Inc.<br>(218)727-4332 x105<br><br>----- "Douglas Mortensen" <doug@impalanetworks.com> wrote:
<br>>
<title>Asterisk daemon dies about once per day</title>
<!-- Converted from text/plain format -->
<p><font size="2">I have an asterisk system where the asterisk daemon dies typically at least once per day. It is running in the wrapper safe_asterisk, which automatically starts the daemon back up. But we find this unacceptable because when the daemon dies, we usually have active calls drop, and sometimes we have to run asterisk -r -x "module reload" after the daemon starts back up before everything is working well again. Any help or insight would be greatly appreciated.<br>>
<br>>
Here's an overview of our system.<br>>
<br>>
Software<br>>
========<br>>
Distro: Trixbox CE 2.6.1.1 (CentOS 5)<br>>
Linux Kernel: 2.6.18-53.1.4.el5<br>>
Asterisk version: 1.4.21.2-2 (trixbox RPM)<br>>
asterisk-addons: 1.4.6 (trixbox RPM)<br>>
zaptel 1.4.11-1 (trixbox RPM)<br>>
zaptel-modules 1.4.11-1.2.6.18_53.1.4.el5 (trixbox RPM)<br>>
<br>>
Hardware<br>>
========<br>>
Rhino Ceros III (2U short-depth server)<br>>
- Intel Desktop Board DG33FB<br>>
- Intel Pentium D 2.2Ghz (E2200)<br>>
- 1GB RAM<br>>
- 80GB SATA HostRAID Mirror (RAID1)<br>>
- Rhino R1T1-EC Single T1 card (as PRI, using 4 channels + D)<br>>
- Rhino RCB8FXX/1 w 1 FXO Module (2 FXO ports total)<br>>
<br>>
Zaptel<br>>
========<br>>
The cards we are using are mentioned above. Other than that, if it helps, here's what we're doing with our trunks. We are using 4 channels of the PRI (channels 1-4), plus the D-channel for signaling. The PRI is a U.S.-based T1. With the FXO ports, we are sharing 1 with a fax & credit card machine, and the other one is shared with a different fax, coming off of the fax's phone port (so there is pretty much no way for it to ever see or feel anything fax-related).<br>>
<br>>
I've looked a bit at the asterisk/full and messages log, but so far nothing stands out.<br>>
<br>>
I did see in one forum where someone was having a similar problem and it ended up being a problem with the FXO card sometimes detecting fax tones on the line. This is definitely a possibility with one of our FXO ports, but it surprises me that this could kill the asterisk daemon??<br>>
<br>>
I did speak with Rhino tech support about these daemon restarts and he told me this was normal. He said, "I've got an asterisk system at my house, and the daemon dies every few days. Just make sure it gets run from safe_asterisk, and you'll be fine". Initially I thought we could live with that, but because it does give us dropped calls, and we sometimes have to reload the asterisk modules afterward, I would like to see if we can pin it down and resolve it.<br>>
<br>>
Based on forums I've seen, it seems to me that not everyone out there shares the acceptance of their asterisk daemon restarting every day or two, and that it may not be a wide-spread problem. The only 2 other asterisk systems I've dealt with didn't seem to have this problem. One is my company's system, which is also Trixbox, which we've been on since May 2008. We don't use Zaptel. We use SIP based trunks with bandwidth.com. I wonder if there is something with our Zaptel interfaces causing this.<br>>
<br>>
So not being a asterisk guru here, I'd really appreciate any help.<br>>
<br>>
Sincerely,<br>>
-<br>>
Doug Mortensen<br>>
Impala Networks Inc.<br>>
<br>>
</font>
</p>
<br>> _______________________________________________
-- 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</doug@impalanetworks.com></body></html>