Spontaneous Reboot Due To MySQL Lookups ?

Home » Asterisk Users » Spontaneous Reboot Due To MySQL Lookups ?
Asterisk Users 9 Comments

Hello

using Asterisk 1.8.32.

I notice that there is a spontaneous reboot of the Asterisk system from time to time.

When I look in the logs (verbose file) I noticed that every time this occurs it’s at a moment that there is a MySQL action, be it a lookup or an insert/update/delete.

I must say I do have some MySQL queries that occur in my dialplan when a call comes in, to look up different actions to perform on this call.

An idea how to overcome this problem ? Seems a “performance” issue, no ?!

Is it better to have these MySQL queries to be done by an external script (like a php script that I call with the System()-command or a SHELL()-command) ?

Here are some examples from the verbose file.

[Aug 22 15:19:10] VERBOSE[2977] pbx.c: [Aug 22 15:19:10]    

9 thoughts on - Spontaneous Reboot Due To MySQL Lookups ?

  • Ooh, vintage 🙂

    I would recommend (a) update to a current and supported version of Asterisk, and (b) use the ODBC driver.

    If the problem persists then with that setup you’re more likely to get help here or be able to file a bug report, but no-one’s going to fix a problem in 1.8
    now.

    Regards,

    Antony.

    —
    3 logicians walk into a bar. The bartender asks “Do you all want a drink?”
    The first logician says “I don’t know.”
    The second logician says “I don’t know.”
    The third logician says “Yes!”

    Please reply to the list;
    please *don’t* CC me.

    —

  • Woefully out of date. You really need to put your efforts into at least a modest upgrade I use version 13 with MySql queries built into the dialplan on CentOS 6 and have NO such issues, either performance or any restart or reboot. It simply works

    I never used either 1.6 or 1.8, going from 1.4 to version 11, which did require some syntax changes to the dialplan.

    Given that even version 11 is EOL, you really need to put your efforts into doing the migration rather than tracking this one down

    JMO

    John Novack

    Jonas Kellens wrote:

  • Hello

    thank you for your answer.

    If I read your (and others) reaction correctly I can conclude that this is an Asterisk problem and not a problem of MySQL or dialplan logic ?

    You should know that the MySQL database is heavily questioned :

    mysql> show status like ‘%onn%’;
    +————————–+——–+
    | Variable_name            | Value  |
    +————————–+——–+
    | Aborted_connects         | 469    |
    | Connections              | 132762 |
    | Max_used_connections     | 8      |
    | Ssl_client_connects      | 0      |
    | Ssl_connect_renegotiates | 0      |
    | Ssl_finished_connects    | 0      |
    | Threads_connected        | 3      |
    +————————–+——–+
    7 rows in set (0.00 sec)

    I stick to 1.8 because it just works. I had some issues with version 11
    and 13 in the past.

    Regards

    Jonas.

    Op 04-10-18 om 17:49 schreef John Novack:

  • Well, clearly it doesn’t because you’re posting here! In a few days time, the *8-year-old* Asterisk 1.8 line will be *three years past EOL.*
    That means End of Life. Do not use. No more support.

    Now, if you were to bring yourself onto the current 13.x LTS (or perhaps better still wait a few days until the 16.x LTS which will be supported until 2023), then you might get more answers.

    Especially if you explain what issues you had with version 13 in the past.

  • As others have said, clearly it ISN’T “just working” or you would not have posted the question

    To state again, I am using Version 13, though a few minor revisions behind, with MySql, on CentOS 6 and have no rebooting or other MySql related issues

    Clearly you need to state in more detail what issues remain, once you migrate to AT LEAST 13.xx, and state your OS after becoming current with Asterisk, MySql and the OS

    I use MySql on every incoming call, and also maintain call detail records in MySql for every call, and it just simply works, and has for some time.

    Although I may be using it quite differently that you, it simply works. Is this a newly developing issue, or has it persisted for some time What if any changes have been made to the dialplan etc?

    Have you considered a strictly hardware issue? Memory? HD? MB??

    The crystal ball is very cloudy on this one!

    John Novack

    Jonas Kellens wrote:

  • Hi Jonas Kellens,

    Like everybody else, I also recommend to upgrade your Asterisk version, and replace mysql driver with odbc. the one big advantage of odbc driver is its pooling feature, you can configure odbc to create a reusable pool of active connections, so Asterisk does’t needs to reconnect for each query.

    For example with following odbc settings you can achieve 500+ concurrent channels (approx 2500 queries / minute) without any performance issue.

    pooling => yes limit => 16
    pre-connect => yes

    Regards

    Nasir Iqbal

    ICTBroadcast – an Auto Dialer software for ITSP
    <https://www.ictbroadcast.com/how-become-internet-telephony-service-provider-itsp-using-ictbroadcast-sp-edition>
    SMS, Fax and Voice broadcasting & Inbound / Outbound Campaigns http://www.ictbroadcast.com/

  • Hello

    thank you for your answer.

    This does not happen all the time. It happens about once every 4 months. I just can not pinpoint WHEN exactly it occurs. I just see in the verbose logfile that it occurs after a MYSQL insert/update/delete statement.

    If Asterisk 13 handels MYSQL connections in a better way, then indeed I
    should look for upgrade.

    Kind regards.

    Op 05-10-18 om 01:25 schreef John Novack:

  • More significantly, the ODBC driver is generally commented on as being a better connector than the MySQL-specific one; I think that’s where you’re more likely to see the improvement.

    Regards,

    Antony.

    —
    Users don’t know what they want until they see what they get.

    Please reply to the list;
    please *don’t* CC me.

    —