Re: [OpenSIPS-Users] problem in dialplan

2019-07-11 Thread johan de clercq 
No problem Richard.  It’s not trivial to spot.  

And indeed, using an event route is probably the solution of your problem. 

 

From: Users  On Behalf Of Richard Revels
Sent: Thursday, July 11, 2019 2:58 PM
To: OpenSIPS users mailling list 
Subject: Re: [OpenSIPS-Users] problem in dialplan

 

We are using dialplan to create some site specific defaults in the startup 
route.  If this is only encountered on startup I guess changing to an event 
route would work if an event is generated when the rules become available.  
Thank you for surfacing this problem.  It may explain an issue I've been 
looking at for the last few hours.

 

 


  

 

 

Richard Revels  •  System Architect II

900 Main Campus Drive, Suite 100, Raleigh, NC 27606

 

m: 919-578-3421  •  o: 919-727-4614

e: rrev...@bandwidth.com  

 

 

On Thu, Jul 4, 2019 at 4:21 AM johan de clercq mailto:jo...@democon.be> > wrote:

Speaking just for myself. 

 

As opensips gains traction in production systems, the error when the rules are 
not loaded should be more clear, now it is : “No information available for dpid 
“.  

Secondly, this problem/issue is not trivial to find, therefore this should be 
seen in the logs on very low loglevels (0 or 1).

 

BR,

 

From: Users mailto:users-boun...@lists.opensips.org> > On Behalf Of Liviu Chircu
Sent: Thursday, July 4, 2019 10:07 AM
To: users@lists.opensips.org  
Subject: Re: [OpenSIPS-Users] problem in dialplan

 

The issue was cleared off-list.  After a successful startup, it would
take a while before the dialplan rules would become available, since child
process #1, responsible for loading the dialplan rules was stuck in
a DNS lookup while loading the drouting rules.

This behavior was introduced in OpenSIPS 2.4.

As I see it, an added problem is that script writers must now additionally
write opensips.cfg code that handles the "rules are not yet available"
case while processing SIP traffic.  And I do not recall any support for
distinguishing between "rules not available" and "rule not matched" in any
of the data matching modules.

The question is: is this "post-startup data unavailability" glitch
something worth paying attention to, or is it harmless?  Example affected
modules:  drouting, dialplan

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 02.07.2019 19:51, johan de clercq wrote:

 

___
Users mailing list
Users@lists.opensips.org  
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org  
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] problem in dialplan

2019-07-11 Thread Richard Revels 
We are using dialplan to create some site specific defaults in the startup
route.  If this is only encountered on startup I guess changing to an event
route would work if an event is generated when the rules become available.
Thank you for surfacing this problem.  It may explain an issue I've been
looking at for the last few hours.



[image: BandwidthMaroon.png]



Richard Revels  •  System Architect II

900 Main Campus Drive, Suite 100, Raleigh, NC 27606



m: 919-578-3421  •  o: 919-727-4614

e: rrev...@bandwidth.com


On Thu, Jul 4, 2019 at 4:21 AM johan de clercq  wrote:

> Speaking just for myself.
>
>
>
> As opensips gains traction in production systems, the error when the rules
> are not loaded should be more clear, now it is : “No information available
> for dpid “.
>
> Secondly, this problem/issue is not trivial to find, therefore this should
> be seen in the logs on very low loglevels (0 or 1).
>
>
>
> BR,
>
>
>
> *From:* Users  *On Behalf Of *Liviu
> Chircu
> *Sent:* Thursday, July 4, 2019 10:07 AM
> *To:* users@lists.opensips.org
> *Subject:* Re: [OpenSIPS-Users] problem in dialplan
>
>
>
> The issue was cleared off-list.  After a successful startup, it would
> take a while before the dialplan rules would become available, since child
> process #1, responsible for loading the dialplan rules was stuck in
> a DNS lookup while loading the drouting rules.
>
> This behavior was introduced in OpenSIPS 2.4.
>
> As I see it, an added problem is that script writers must now additionally
> write opensips.cfg code that handles the "rules are not yet available"
> case while processing SIP traffic.  And I do not recall any support for
> distinguishing between "rules not available" and "rule not matched" in any
> of the data matching modules.
>
> The question is: is this "post-startup data unavailability" glitch
> something worth paying attention to, or is it harmless?  Example affected
> modules:  drouting, dialplan
>
> Liviu Chircu
>
> OpenSIPS Developer
>
> http://www.opensips-solutions.com
>
> On 02.07.2019 19:51, johan de clercq wrote:
>
>
>
> ___
>
> Users mailing list
>
> Users@lists.opensips.org
>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Opensips stops responding

2019-07-11 Thread S. Rosenberg 
I want to add that a restart of OpenSIPs fixed the problem every time, I
didnt restart the MySQL server.



--
Sent from: 
http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Opensips stops responding

2019-07-11 Thread Schneur Rosenberg 
Hi, I've had recently a few times that OpenSIPSs didnt crash but it
stopped responding to certain requests, perhaps INVITES that requeired
DB access, but I havent verified it becuase I always wanted to bring
it back up ASAP because it seems like it did respond to my requests
that my keepalived VRRP script which sends a notify to OpenSIPs and
OpenSIPS does a DB lookup and only on success it returns a true thats
how I make sure that MYSQL is working in addition to  OpenSIPs, but
opensips seems to have responded because it did not failover, and
thats why I didnt have time to investigate further to which requests
it responds and to which it didnt.

Here are the syslogs from the time of the crash, maybe it can shed
some light to the issue, the query in there that failed is the query
from keepalived, I assume it failed only once and then did respond,
otherwise the IP would of failed over to the backup, but its only an
assumption.

Jul 10 20:13:13 sipsvr1 /sbin/opensips[29446]:
INFO:db_mysql:switch_state_to_disconnected: disconnect event for
0x7f2ba43e7600
Jul 10 20:13:13 sipsvr1 /sbin/opensips[29446]:
INFO:db_mysql:reset_all_statements: resetting all statements on
connection: (0x7f2ba44062a0) 0x7f2ba43e7600
Jul 10 20:13:13 sipsvr1 /sbin/opensips[29446]:
INFO:db_mysql:connect_with_retry: re-connected successful for
0x7f2ba43e7600
Jul 10 20:13:13 sipsvr1 /sbin/opensips[29446]:
INFO:db_mysql:db_mysql_do_prepared_query: reconnected to mysql server
-> re-init the statement
Jul 10 20:13:13 sipsvr1 /sbin/opensips[29486]:
WARNING:core:handle_timer_job: utimer job  has a 3 us
delay in execution
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29400]:
INFO:clusterer:do_action_trans_2: Ping reply not received, node [2] is
down
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29400]:
INFO:clusterer:do_action_trans_2: Ping reply not received, node [2] is
down
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29478]:
INFO:clusterer:handle_internal_msg: Node [2] is UP
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29478]:
INFO:clusterer:handle_internal_msg: Node [2] is UP
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29422]:
INFO:presence:update_presentity: *** found in db but not in htable
[a.1561468443.29425.374568.2]
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29419]:
INFO:presence:update_presentity: *** found in db but not in htable
[a.1561468443.29431.1000819.1]
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29428]:
INFO:presence:update_presentity: *** found in db but not in htable
[a.1561468443.29411.161103.9]
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29446]:
CRITICAL:db_mysql:wrapper_single_mysql_stmt_execute: driver error
(1180): Got error 35 "Resource deadlock avoided" during COMMIT
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29446]:
ERROR:usrloc:db_update_ucontact: updating database failed
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29446]: ERROR:usrloc:wb_timer:
updating contact in db failed
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29388]:
CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error
(1047): WSREP has not yet prepared node for application use
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29388]:
ERROR:core:db_do_raw_query: error while submitting query
Jul 10 20:13:15 sipsvr1 /sbin/opensips[29388]:
ERROR:avpops:db_query_avp: raw_query failed: db0(usr_preferences)
select domain from domain where domain='...
Jul 10 20:13:15 sipsvr1 Keepalived_vrrp[514]: pid 2092 exited with status 1
Jul 10 20:13:16 sipsvr1 /sbin/opensips[29428]:
INFO:presence:update_presentity: *** found in db but not in htable
[a.1561468443.29422.274079.61]
Jul 10 20:13:16 sipsvr1 /sbin/opensips[29429]:
INFO:presence:update_presentity: *** found in db but not in htable
[a.1561468443.29421.236751.61]
Jul 10 20:13:16 sipsvr1 /sbin/opensips[29425]:
INFO:presence:update_presentity: *** found in db but not in htable
[a.1561468443.29419.224887.28]
Jul 10 20:13:16 sipsvr1 /sbin/opensips[29422]:
INFO:presence:update_presentity: *** found in db but not in htable
[a.1561468443.29413.165448.9]
Jul 10 20:13:16 sipsvr1 /sbin/opensips[29419]:
INFO:presence:update_presentity: *** found in db but not in htable
[a.1561468443.29429.711965.1]
Jul 10 20:13:16 sipsvr1 /sbin/opensips[29411]:
INFO:presence:update_presentity: *** found in db but not in htable
[a.1561468443.29431.1000786.2]
Jul 10 20:13:16 sipsvr1 /sbin/opensips[29428]:
INFO:presence:update_presentity: *** found in db but not in htable
[a.1561468443.29411.161104.10]
Jul 10 20:13:16 sipsvr1 /sbin/opensips[29421]:
INFO:presence:update_presentity: *** found in db but not in htable
[a.1561468443.29419.224888.10]
Jul 10 20:13:16 sipsvr1 /sbin/opensips[29433]:
INFO:presence:update_presentity: *** found in db but not in htable
[a.1561468443.29421.236752.28]

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users