<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hello Henning,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Regarding your question about whether the auto_reconnect parameter was set or not, I had it set to auto_reconnect but unfortunately it made no difference.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">On another note, I received your comment on github about core file and gdb trace. I will look into getting that info to you. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thank you.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Karthik</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 25, 2019 at 3:16 AM Henning Westerholt <<a href="mailto:hw@kamailio.org">hw@kamailio.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am Mittwoch, 23. Januar 2019, 18:13:26 CET schrieb Karthik Srinivasan:<br>
> An update regarding this item:<br>
> <br>
> I have tested release 5.1.x and 5.2.x and neither release resolves the<br>
> issue.<br>
> <br>
> However I did notice in the master branch that there is new code that is<br>
> related to this issue.<br>
> <br>
> <a href="https://github.com/kamailio/kamailio/issues/1681" rel="noreferrer" target="_blank">https://github.com/kamailio/kamailio/issues/1681</a><br>
<br>
Hello Karthik,<br>
<br>
indeed in current git master there is an extension in the sqlops module to <br>
allow the startup with an offline database.<br>
<br>
> In issue 1681 there is code that allows Kamailio to start even if a<br>
> database connection can not be established. Queries attempting to run<br>
> against the offline database fail gracefully. And once the database is<br>
> back online, a connection is established and queries against it are<br>
> successful.<br>
> <br>
> However, if at some later point I shut down the database, we're back to the<br>
> original issue that i reported. Kamailio crashes with the same output as<br>
> listed before except the first query that is attempted against the offline<br>
> db causes the crash in this master branch unlike previously (branch 5.0.x,<br>
> 5.1.x, 5.2.x) the first attempt fails, tries again and fails, and the<br>
> second attempt causes the crash. Regardless, the output is more or less<br>
> the same and Kamailio is down.<br>
<br>
This is probably because the purpose of this extensions was extending the <br>
startup process and not especially targeted to this re-connection. This is <br>
usually handled in the db_* modules.<br>
<br>
> I suspect this might be the same behavior even if one is not using an odbc<br>
> driver; but maybe not.<br>
<br>
The db_unixodbc module supports the auto_reconnect (as other db_* modules). Do <br>
you enabled or disabled this parameter?<br>
<br>
> Anyways, i will open an issue on github for this and hopefully the code<br>
> change to resolve this is relatively straightforward.<br>
<br>
Thank you.<br>
<br>
Best regards,<br>
<br>
Henning<br>
<br>
> Henning, thanks again for your feedback on this.<br>
> <br>
> Karthik<br>
> <br>
> <br>
> <br>
> <br>
> On Mon, Jan 21, 2019 at 9:09 AM Karthik Srinivasan <<a href="mailto:ksriniva2002@gmail.com" target="_blank">ksriniva2002@gmail.com</a>><br>
> <br>
> wrote:<br>
> > Henning,<br>
> > <br>
> > Thank you for the response.<br>
> > <br>
> > I will open an issue and test out the latest releases.<br>
> > <br>
> > Thanks again for the feedback.<br>
> > <br>
> > Karthik<br>
> > <br>
> > On Sun, Jan 20, 2019 at 9:31 AM Henning Westerholt <<a href="mailto:hw@kamailio.org" target="_blank">hw@kamailio.org</a>><br>
> > <br>
> > wrote:<br>
> >> Am Freitag, 18. Januar 2019, 18:28:09 CET schrieb Karthik Srinivasan:<br>
> >> > I am testing how kamailio reacts to various database conditions. One<br>
> >> <br>
> >> such<br>
> >> <br>
> >> > condition is if the database engine is simply shut down (that is,<br>
> >> <br>
> >> database<br>
> >> <br>
> >> > server process no longer running, tcp listening socket closed, etc...)<br>
> >> > <br>
> >> > I am utilizing the db_unixodbc module to connect to an Informix<br>
> >> > database<br>
> >> > engine.<br>
> >> > <br>
> >> > I am currently running on Kamailio version 5.0.<br>
> >> > <br>
> >> > I have a test query that executes against the database engine every 10<br>
> >> > seconds.<br>
> >> > <br>
> >> > Here is what i have noticed if i shut down the database engine at some<br>
> >> > point after i run Kamailio.<br>
> >> > <br>
> >> > the first test query that attempts to run against the db engine fails;<br>
> >> <br>
> >> it<br>
> >> <br>
> >> > tries to reconnect and fails.<br>
> >> > <br>
> >> > The second test query (10 seconds after the 1st) results in a SIG_CHILD<br>
> >> <br>
> >> and<br>
> >> <br>
> >> > shuts down the entire Kamailio process.<br>
> >> > <br>
> >> > Has anyone experienced this? Is there a solution to this? Ideally<br>
> >> > the<br>
> >> > second query should also fail and return gracefully; and ideally<br>
> >> > queries<br>
> >> > continue to fail until the database engine is back up.<br>
> >> <br>
> >> Hello Karthik,<br>
> >> <br>
> >> Kamailio should not crash because of this error. The db_unixodbc module<br>
> >> is not<br>
> >> that widely used (compared to db_mysql), but nevertheless it shouldn't<br>
> >> crash.<br>
> >> <br>
> >> Can you create an issue in our tracker on github for this:<br>
> >> <a href="https://github.com/kamailio/kamailio/issues" rel="noreferrer" target="_blank">https://github.com/kamailio/kamailio/issues</a><br>
> >> <br>
> >> It would be great if you can also try with the latest stable version of<br>
> >> 5.1.x<br>
> >> or 5.2.x, there have been some changes in the db_unixodbc module since<br>
> >> the<br>
> >> release of 5.0.<br>
> >> <br>
> >> Best regards,<br>
> >> <br>
> >> Henning<br>
> >> <br>
> >> > See logs below:<br>
> >> > <br>
> >> > Jan 17 20:07:25 [29297]: INFO: (s) SQL query: FIRST TEST QUERY<br>
> >> > Jan 17 20:07:25 [29297]: ERROR: db_unixodbc [dbase.c:135]:<br>
> >> > db_unixodbc_submit_query(): rv=-1. Query= FIRST TEST QUERY<br>
> >> > Jan 17 20:07:25 [29297]: ERROR: db_unixodbc [connection.c:220]:<br>
> >> > db_unixodbc_extract_error():<br>
> >> > unixodbc:SQLExecDirect=08S01:1:-11020:[Informix][Informix ODBC<br>
> >> > Driver]Communication link failure.<br>
> >> > Jan 17 20:07:25 [29297]: ERROR: db_unixodbc [dbase.c:59]: reconnect():<br>
> >> > Attempting DB reconnect<br>
> >> > Jan 17 20:07:25 [29297]: ERROR: db_unixodbc [dbase.c:74]: reconnect():<br>
> >> > failed to connect<br>
> >> > Jan 17 20:07:25 [29297]: ERROR: db_unixodbc [connection.c:220]:<br>
> >> > db_unixodbc_extract_error():<br>
> >> > unixodbc:SQLDriverConnect=08002:1:0:[unixODBC][Driver<br>
> >> > Manager]Connection<br>
> >> > name in use<br>
> >> > Jan 17 20:07:25 [29297]: ERROR: db_unixodbc [connection.c:220]:<br>
> >> > db_unixodbc_extract_error():<br>
> >> > unixodbc:SQLDriverConnect=HY010:2:-11067:[Informix][Informix ODBC<br>
> >> > Driver]Function sequence error.<br>
> >> <br>
> >> > Jan 17 20:07:25 [29297]: ERROR: <core> [db_query.c:181]:<br>
> >> db_do_raw_query():<br>
> >> > error while submitting query<br>
> >> > Jan 17 20:07:25 [29297]: ERROR: sqlops [sql_api.c:265]: sql_do_query():<br>
> >> > cannot do the query FIRST TEST QUERY<br>
> >> > Jan 17 20:07:25 [29297]: INFO: (s) [123] SQL ret: fail (-1)<br>
> >> > Jan 17 20:07:25 [29297]: INFO: (s) [123] SQL res: no rows<br>
> >> > Jan 17 20:07:35 [29297]: INFO: (s) [123] SQL query: 10 seconds later<br>
> >> > the<br>
> >> > SECOND TEST QUERY (it's the same query as the first one)<br>
> >> > Jan 17 20:07:35 [29301]: CRITICAL: <core> [core/pass_fd.c:277]:<br>
> >> > receive_fd(): EOF on 28<br>
> >> <br>
> >> > Jan 17 20:07:35 [29283]: ALERT: <core> [main.c:744]: handle_sigs():<br>
> >> child<br>
> >> <br>
> >> > process 29297 exited by a signal 11<br>
> >> > Jan 17 20:07:35 [29283]: ALERT: <core> [main.c:747]: handle_sigs():<br>
> >> > core<br>
> >> > was not generated<br>
> >> > Jan 17 20:07:35 [29283]: INFO: <core> [main.c:759]: handle_sigs():<br>
> >> > terminating due to SIGCHLD<br>
> >> > Jan 17 20:07:35 [29301]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29295]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29291]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29288]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29300]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29284]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29286]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29293]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29289]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29287]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29292]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29296]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29298]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29299]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29285]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29294]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29290]: INFO: <core> [main.c:814]: sig_usr(): signal<br>
> >> > 15<br>
> >> > received<br>
> >> > Jan 17 20:07:35 [29283]: INFO: <core> [core/sctp_core.c:53]:<br>
> >> > sctp_core_destroy(): SCTP API not initialized<br>
<br>
-- <br>
Henning Westerholt - <a href="https://skalatan.de/blog/" rel="noreferrer" target="_blank">https://skalatan.de/blog/</a><br>
Kamailio services - <a href="https://skalatan.de/services" rel="noreferrer" target="_blank">https://skalatan.de/services</a><br>
Kamailio security assessment - <a href="https://skalatan.de/de/assessment" rel="noreferrer" target="_blank">https://skalatan.de/de/assessment</a><br>
</blockquote></div>