Hello,

After upgrading to 0.9 i started to notice that Freepbx would fail to apply changes every 3 goes. I found that the Asterisk server was core dumping on the 3rd reload.

I thought it may have been a hardware problem to start with, but have since seen 1 other person on #elastix IRC who has queried about the exact same problem.

Can anyone shed some lite on this ? I have several core dump files in /tmp.

Linux version 2.6.18-8.el5 (mockbuild@builder4.centos.org) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Thu Mar 15 19:57:35 EDT 2007
Asterisk 1.4.17
Elastix 0.9.2-4

Thank you.<br><br>Post edited by: styelz, at: 2008/01/17 10:45

After looking through /var/log/asterisk/full i noticed the following.

On the 2nd reload, i get this in the logs.


[Jan 19 03:02:49] WARNING[2786] channel.c: Already have a handler for type 'UniCall'
[Jan 19 03:02:49] ERROR[2786] chan_unicall.c: Unable to register channel class UniCall
[Jan 19 03:02:49] VERBOSE[2786] logger.c: == Unregistered channel type 'UniCall'
[Jan 19 03:02:49] WARNING[2786] chan_unicall.c: Reload of chan_unicall.so is unsuccessful!
[Jan 19 03:02:49] VERBOSE[2786] logger.c: -- Reloading module 'codec_gsm.so' (GSM Coder/Decoder)


When i reload the 3rd time, it core dumps. I see this in the logs.



[Jan 19 03:02:53] WARNING[2786] channel.c: Already have a handler for type 'UniCall'
[Jan 19 03:02:53] ERROR[2786] chan_unicall.c: Unable to register channel class UniCall

** IT CORE DUMPS HERE **

[Jan 19 03:02:57] VERBOSE[2810] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log


I have also upgraded the kernel to 2.6.18-53.1.4.el5.centos.plus but still the same.

Preventing chan_unicall.so from loading seems to be a temporary fix for this problem.

Add noload =&gt; chan_unicall.so to /etc/asterisk/modules.conf<br><br>Post edited by: styelz, at: 2008/01/19 03:35