Frequent Asterisk Restarts

Home » Asterisk Users » Frequent Asterisk Restarts
Asterisk Users 9 Comments

Hi all,

I’ve recently started experiencing frequent * restarts, usually caused by a
segfault. So, I moved my users to a different server and the same thing
happened. It’s a fairly busy box, so I considered memory exhaustion. Nope,
not even swapping.

Now I’m thinking file handles, but I won’t be able to test until tonight. Is
there anything else I should look at?

I’m (re)starting * via inittab. I’m assuming I can just use a script that
contains the proper ulimit incantation to increase the file handles…?

Any other advise on how to improve stability? BTW, both servers are running
Asterisk 1.6.2.9 w/ realtime sip/voicemail.

9 thoughts on - Frequent Asterisk Restarts

  • I am having similar issues with Asterisk 1.4.26

    It happens at random times; could be once a day or a few hours in between up to a month or so.

    Haven’t found a solution to my problem yet either.

  • The Asterisk source tree has a document with instructions on getting a backtrace from the segfaults so you can report it on the issue tracker.

  • Unfortunately, I didn’t compile with DON’T_OPTIMIZE. Would this render my backtrace.txt completely useless or should I still submit?

    Thanks,

  • I’ll explore the options outlined in the document below, later tonight.

    However, I’ve been able to reproduce the problem! It seems that when one of
    my users, at a particular site, transfers a call to another extension,
    asterisk bounces.

    They’re using Polycom 301’s and 501’s with SIP version 3.1.4.0070.

    Without having gotten the debug info, yet, is there anything else I can look
    at?

    TIA.

  • You might want to see if it is
    1. a phone or an asterisk transfer – phone transfer hits button on phone and
    does attended/blind transfer that way; asterisk transfer initiated with *1
    or #2 (whatever value is specified in features.conf)
    2. attended or blind transfer.

  • It’s a phone-based transfer.

    The attended transfers seem to give them the most problems. They say that if
    they hit the transfer softkey while the destination extension is still
    ringing, it tends to work well.

    Mike.

  • Don’t bother. It makes the issue more aparent, but has a very large
    performance hit. In some cases it will also make the problem go away (in
    some odd races).

  • Sorry, just need to double check I understand what you’re saying here.
    Are you saying that compiling with the DONT_OPTIMIZE (and
    BETTER_BACKTRACE) flags causes a big performance hit to the asterisk
    service?