Re: [OpenSIPS-Users] Opensips Postgresql Seq Create Error

[Nathaniel L. Keeling III]

Razvan,

Yes, the tables were created. I didn't know if this was significant.

Thanks

Nathaniel L Keeling

On 3/9/17 4:48 AM, Răzvan Crainea wrote:
> Hi, Nathaniel!
>
> Desipte the error, are the location and the tls_mgm tables created?
>
> Best regards,
> Răzvan Crainea
> OpenSIPS Solutions
> www.opensips-solutions.com
> On 03/09/2017 10:04 AM, Nathaniel L. Keeling III wrote:
>>
>> I am getting this error when initially creating the opensips
>> database. I am using Opensips v 2.2 with Postgresql 9.2.6 on Centos 7
>>
>> [root@sip_core_proxy sbin]# ./opensipsdbctl create
>> PGSQL password for postgres:
>> INFO: creating database opensips ...
>> *ERROR:  relation "location_id_seq" does not exist**
>> **ERROR:  relation "tls_mgm_id_seq" does not exist*
>> INFO: Core OpenSIPS tables successfully created.
>>
>> Thanks
>>
>> Nathaniel L Keeling
>>
>>
>>
>>
>> ___
>> 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] Quest to find memory leak

[John Nash]

If I use 2.2 will it give clearer picture of memory allocation? or 2.3

On Thu, Mar 9, 2017 at 7:21 PM, Răzvan Crainea  wrote:

> There's no need for that. No function should leak in any circumstances :)
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/09/2017 03:27 PM, John Nash wrote:
>
> OK..May i send you my script privately?
>
> On Thu, Mar 9, 2017 at 6:13 PM, Răzvan Crainea 
> wrote:
>
>> Hi, John!
>>
>> No, I nothing is suspicious. Definitely not from the drouting module.
>> Try to make two captures: one after 10 calls, another one after 20 calls.
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>> On 03/09/2017 01:50 PM, John Nash wrote:
>>
>> Do you see anything suspicious in the latest mem dump?
>>
>> On Wed, Mar 8, 2017 at 7:20 PM, John Nash  wrote:
>>
>>> One more useful info. I disabled drouting functions and just rewrote
>>> RURI to hardcoded address keeping rest of the functions same and I do not
>>> see drop in private memory of that process.
>>>
>>> On Wed, Mar 8, 2017 at 4:40 PM, John Nash 
>>> wrote:
>>>
 OK Here is the dump
 https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8


 I increased syslog message rate to 50, Made around 10 call
 attempts. Waited for some time and made sure no call is on server and then
 sent signal to dump memory to the process ID i suspect.

 On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea 
 wrote:

> No, you should not kill any process. Simply send a SIGUSR1 to the
> process you suspect.
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/08/2017 12:28 PM, John Nash wrote:
>
> Sorry...Should I kill only the process where i see memory leak?
>
>
> ___
> 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] Quest to find memory leak

[Răzvan Crainea]

There's no need for that. No function should leak in any circumstances :)

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 03/09/2017 03:27 PM, John Nash wrote:

OK..May i send you my script privately?

On Thu, Mar 9, 2017 at 6:13 PM, Răzvan Crainea > wrote:


Hi, John!

No, I nothing is suspicious. Definitely not from the drouting module.
Try to make two captures: one after 10 calls, another one after 20
calls.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com 

On 03/09/2017 01:50 PM, John Nash wrote:

Do you see anything suspicious in the latest mem dump?

On Wed, Mar 8, 2017 at 7:20 PM, John Nash > wrote:

One more useful info. I disabled drouting functions and just
rewrote RURI to hardcoded address keeping rest of the
functions same and I do not see drop in private memory of
that process.

On Wed, Mar 8, 2017 at 4:40 PM, John Nash
> wrote:

OK Here is the dump
https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8



I increased syslog message rate to 50, Made around 10
call attempts. Waited for some time and made sure no call
is on server and then sent signal to dump memory to the
process ID i suspect.

On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea
> wrote:

No, you should not kill any process. Simply send a
SIGUSR1 to the process you suspect.

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com


On 03/08/2017 12:28 PM, John Nash wrote:

Sorry...Should I kill only the process where i see
memory leak?


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

Re: [OpenSIPS-Users] Quest to find memory leak

[John Nash]

OK..May i send you my script privately?

On Thu, Mar 9, 2017 at 6:13 PM, Răzvan Crainea  wrote:

> Hi, John!
>
> No, I nothing is suspicious. Definitely not from the drouting module.
> Try to make two captures: one after 10 calls, another one after 20 calls.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/09/2017 01:50 PM, John Nash wrote:
>
> Do you see anything suspicious in the latest mem dump?
>
> On Wed, Mar 8, 2017 at 7:20 PM, John Nash  wrote:
>
>> One more useful info. I disabled drouting functions and just rewrote RURI
>> to hardcoded address keeping rest of the functions same and I do not see
>> drop in private memory of that process.
>>
>> On Wed, Mar 8, 2017 at 4:40 PM, John Nash  wrote:
>>
>>> OK Here is the dump
>>> https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8
>>>
>>>
>>> I increased syslog message rate to 50, Made around 10 call attempts.
>>> Waited for some time and made sure no call is on server and then sent
>>> signal to dump memory to the process ID i suspect.
>>>
>>> On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea 
>>> wrote:
>>>
 No, you should not kill any process. Simply send a SIGUSR1 to the
 process you suspect.

 Răzvan Crainea
 OpenSIPS Solutionswww.opensips-solutions.com

 On 03/08/2017 12:28 PM, John Nash wrote:

 Sorry...Should I kill only the process where i see memory leak?

 On Wed, Mar 8, 2017 at 3:41 PM, Răzvan Crainea 
 wrote:

> use only memdump set to 1.
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/08/2017 12:11 PM, John Nash wrote:
>
> Ok i will give another try what should be the values of memdump and
> memlog
>
> On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea 
> wrote:
>
>> Hi, John!
>>
>> The traces you showed me are incomplete: they do not have all the
>> memory chunks allocated, thus I can't say wether something is wrong or 
>> not.
>> As I said earlier, it is normal for opensips to use extra memory
>> every call. But after a while, this should stabilize. After a while might
>> mean more than 1000k calls. As long as you never reach the upper limit of
>> the memory, you can't conclude that there is a memory leak. Even then,
>> you're limit might be too low for the kind of traffic you are doing, so 
>> it
>> still might not be a memory leak. But only then it is worth to 
>> investigate.
>> When we investigate, we need all the data (i.e. the entire trace of
>> the memory dump).
>> So please try to send as many calls as possilble, and if this issue
>> still persists, make a pkg memory dump when the server is in idle mode 
>> and
>> send it over.
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>> On 03/08/2017 11:26 AM, John Nash wrote:
>>
>> any suggestion for me?..should i try to crash opensips by sending
>> many calls?
>>
>> On Tue, Mar 7, 2017 at 4:54 PM, John Nash 
>> wrote:
>>
>>> version: opensips 2.1.5 (x86_64/linux)
>>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
>>> DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN
>>> 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>> git revision: 39b19dd
>>> main.c compiled on 19:27:59 Mar  5 2017 with gcc 4.4.7
>>>
>>> memory stabilizing in time? Or it is continously decreasing?
>>> Yes, that's how you should make the dump.
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>
>>>
>>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://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 
 listUsers@lists.opensips.orghttp://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 
> 

Re: [OpenSIPS-Users] Quest to find memory leak

[Răzvan Crainea]

Hi, John!

No, I nothing is suspicious. Definitely not from the drouting module.
Try to make two captures: one after 10 calls, another one after 20 calls.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 03/09/2017 01:50 PM, John Nash wrote:

Do you see anything suspicious in the latest mem dump?

On Wed, Mar 8, 2017 at 7:20 PM, John Nash > wrote:


One more useful info. I disabled drouting functions and just
rewrote RURI to hardcoded address keeping rest of the functions
same and I do not see drop in private memory of that process.

On Wed, Mar 8, 2017 at 4:40 PM, John Nash > wrote:

OK Here is the dump
https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8



I increased syslog message rate to 50, Made around 10 call
attempts. Waited for some time and made sure no call is on
server and then sent signal to dump memory to the process ID i
suspect.

On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea
> wrote:

No, you should not kill any process. Simply send a SIGUSR1
to the process you suspect.

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com 

On 03/08/2017 12:28 PM, John Nash wrote:

Sorry...Should I kill only the process where i see memory
leak?

On Wed, Mar 8, 2017 at 3:41 PM, Răzvan Crainea
> wrote:

use only memdump set to 1.

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com


On 03/08/2017 12:11 PM, John Nash wrote:

Ok i will give another try what should be the values
of memdump and memlog

On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea
>
wrote:

Hi, John!

The traces you showed me are incomplete: they do
not have all the memory chunks allocated, thus I
can't say wether something is wrong or not.
As I said earlier, it is normal for opensips to
use extra memory every call. But after a while,
this should stabilize. After a while might mean
more than 1000k calls. As long as you never
reach the upper limit of the memory, you can't
conclude that there is a memory leak. Even then,
you're limit might be too low for the kind of
traffic you are doing, so it still might not be
a memory leak. But only then it is worth to
investigate.
When we investigate, we need all the data (i.e.
the entire trace of the memory dump).
So please try to send as many calls as
possilble, and if this issue still persists,
make a pkg memory dump when the server is in
idle mode and send it over.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com


On 03/08/2017 11:26 AM, John Nash wrote:

any suggestion for me?..should i try to crash
opensips by sending many calls?

On Tue, Mar 7, 2017 at 4:54 PM, John Nash
> wrote:

version: opensips 2.1.5 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST,
SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC,
FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024,
MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt,
epoll_et, sigio_rt, select.
git revision: 39b19dd
main.c compiled on 19:27:59 Mar  5 2017
with gcc 4.4.7

memory stabilizing in time? Or it is
continously decreasing?
Yes, that's how you should make the dump.

Best 

Re: [OpenSIPS-Users] Quest to find memory leak

[John Nash]

Do you see anything suspicious in the latest mem dump?

On Wed, Mar 8, 2017 at 7:20 PM, John Nash  wrote:

> One more useful info. I disabled drouting functions and just rewrote RURI
> to hardcoded address keeping rest of the functions same and I do not see
> drop in private memory of that process.
>
> On Wed, Mar 8, 2017 at 4:40 PM, John Nash  wrote:
>
>> OK Here is the dump
>> https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8
>>
>>
>> I increased syslog message rate to 50, Made around 10 call attempts.
>> Waited for some time and made sure no call is on server and then sent
>> signal to dump memory to the process ID i suspect.
>>
>> On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea 
>> wrote:
>>
>>> No, you should not kill any process. Simply send a SIGUSR1 to the
>>> process you suspect.
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>
>>> On 03/08/2017 12:28 PM, John Nash wrote:
>>>
>>> Sorry...Should I kill only the process where i see memory leak?
>>>
>>> On Wed, Mar 8, 2017 at 3:41 PM, Răzvan Crainea 
>>> wrote:
>>>
 use only memdump set to 1.

 Răzvan Crainea
 OpenSIPS Solutionswww.opensips-solutions.com

 On 03/08/2017 12:11 PM, John Nash wrote:

 Ok i will give another try what should be the values of memdump and
 memlog

 On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea 
 wrote:

> Hi, John!
>
> The traces you showed me are incomplete: they do not have all the
> memory chunks allocated, thus I can't say wether something is wrong or 
> not.
> As I said earlier, it is normal for opensips to use extra memory every
> call. But after a while, this should stabilize. After a while might mean
> more than 1000k calls. As long as you never reach the upper limit of the
> memory, you can't conclude that there is a memory leak. Even then, you're
> limit might be too low for the kind of traffic you are doing, so it still
> might not be a memory leak. But only then it is worth to investigate.
> When we investigate, we need all the data (i.e. the entire trace of
> the memory dump).
> So please try to send as many calls as possilble, and if this issue
> still persists, make a pkg memory dump when the server is in idle mode and
> send it over.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/08/2017 11:26 AM, John Nash wrote:
>
> any suggestion for me?..should i try to crash opensips by sending many
> calls?
>
> On Tue, Mar 7, 2017 at 4:54 PM, John Nash 
> wrote:
>
>> version: opensips 2.1.5 (x86_64/linux)
>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
>> DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>> MAX_URI_SIZE 1024, BUF_SIZE 65535
>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>> git revision: 39b19dd
>> main.c compiled on 19:27:59 Mar  5 2017 with gcc 4.4.7
>>
>> memory stabilizing in time? Or it is continously decreasing?
>> Yes, that's how you should make the dump.
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>>
>>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


 ___
 Users mailing 
 listUsers@lists.opensips.orghttp://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 
>>> listUsers@lists.opensips.orghttp://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] crashing in 2.2.2

[Richard Robson]

Hi Bogdan,

Yup its under load.

There aren't any errors apart from the WARNING:core:utimer_ticker: 
utimer task  already scheduled for


The live script doesn't have the failover on the 404/50X responses and 
copes with the load no problem and never crashes.
It's only when I try and do the failover with the use_next_gw and the 
load ramps up to about 1/4 of the normal load. So in testing a made a 
few calls and its works fine, but when I put it live its starts crashing 
at about 09:15 when the users start coming on line, but our load is 
highest after 11:00am so there is load, but not a large amount. It 
starts crashing at around 50 concurrent calls and maybe 5 or 6 cps.


I can reproduce it on our test server, but it will disrupt traffic, so 
i'd rather do that out of hours, but if I sipp to an invalid number I 
can reproduce it but all the cores look similar to me too and have the 
reply message in them but i'm no expert at decoding the back traces.


I can get some more Cores for you but I suspect that they will all be 
similar.  I would have thought though, that would make the debuging easier?



Let me know id you need anything else from me.

Regards,

Richard

On 07/03/2017 21:10, Bogdan-Andrei Iancu wrote:

Hi Richard,

Sorry for the slow reply - is this crash happing only under some 
++load ? do you see any errors from OpenSIPS prior to the crash ?


I noticed that the backtraces in the corefiles are similar - how easy 
is for you to reproduce it ?


Regards,

Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/07/2017 12:28 PM, Richard Robson wrote:

Hi,

I've gone over the script and as far as I can see its working as 
expected until the traffic remps up and then opensips crashes.


cores:
http://pastebin.com/CgN0h40K
http://pastebin.com/ay5TS8zD
http://pastebin.com/PGn3AqmU

Regards,

Richard

On 06/03/2017 12:14, Richard Robson wrote:

Hi<

I've tested this on the latest 2.2.3 with the same results.

http://pastebin.com/Uixb3v8G

there were a few of these in the logsd too just before the crash:
Mar  5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: 
WARNING:core:utimer_ticker: utimer task  already 
scheduled for 204079170 ms (now 204079270 ms), it may overlap..
Mar  5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: 
WARNING:core:utimer_ticker: utimer task  already 
scheduled for 204079170 ms (now 204079360 ms), it may overlap..
Mar  5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: 
WARNING:core:utimer_ticker: utimer task  already 
scheduled for 204079170 ms (now 204079460 ms), it may overlap..
Mar  5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: 
WARNING:core:utimer_ticker: utimer task  already 
scheduled for 204079170 ms (now 204079560 ms), it may overlap..
Mar  5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: 
WARNING:core:utimer_ticker: utimer task  already 
scheduled for 204079170 ms (now 204079660 ms), it may overlap..
Mar  5 22:02:28 gl-sip-03 /usr/sbin/opensips[29875]: 
WARNING:core:utimer_ticker: utimer task  already 
scheduled for 204079170 ms (now 204079760 ms), it may overlap..



Regards,

Richard



On 03/03/2017 13:15, Richard Robson wrote:

More cores

http://pastebin.com/MXW2VBhi
http://pastebin.com/T7JFAP2U
http://pastebin.com/u44aaVpWquit
http://pastebin.com/SFKKcGxE
http://pastebin.com/dwSgMsJi
http://pastebin.com/9HdGLm96

I've put 2.2.3 on the dev box now and will try to replicate on that 
box, but its difficult to replicate the traffic artificially. I'll 
try to replicate the fault on the dev box over the weekend. I cant 
do it on the live gateways because it will affect customer traffic.


Regards,

Richard


On 03/03/2017 11:28, Richard Robson wrote:
I've revisited the gateway failover mechanism I had developed in 
order to re route calls to the next gateway on 500's due to 
capacity on the gateways we are using.


we have 3 gateways from one carrier and one from another. The 3 
have 4 cps and will return a 503 or 500 if we breach this. The 
single gateway from the other carrier has plenty of capacity and 
should not be a problem so we want to catch this . and route to 
the next gateway.


We are counting the CPS and channel limits and are routing to the 
next gateway if we exceed the limit set, but There are still 
occasions where a 5XX is generated, which results in a rejected call.



We want to stop these rejected calls and therefore want to 
implement the failover mechanism for the 5XX responses. For 6 
months we have been failing over if we think the counts are to 
high on any one gateway without a problem. But when I implement a 
failover on a 5XX response opensips starts crashing.


It's difficult to generate artificial traffic to mimic the real 
traffic, but I've not had a problem with the script in testing. 
Last night I rolled out the new script but by 09:15 this morning 
opensips started crashing 10 times in 5 minutes. This 

Re: [OpenSIPS-Users] Opensips Postgresql Seq Create Error

[Răzvan Crainea]

Hi, Nathaniel!

Desipte the error, are the location and the tls_mgm tables created?

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 03/09/2017 10:04 AM, Nathaniel L. Keeling III wrote:


I am getting this error when initially creating the opensips database. 
I am using Opensips v 2.2 with Postgresql 9.2.6 on Centos 7


[root@sip_core_proxy sbin]# ./opensipsdbctl create
PGSQL password for postgres:
INFO: creating database opensips ...
*ERROR:  relation "location_id_seq" does not exist**
**ERROR:  relation "tls_mgm_id_seq" does not exist*
INFO: Core OpenSIPS tables successfully created.

Thanks

Nathaniel L Keeling




___
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] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10

[Liviu Chircu]

No luck on a CentOS 7.2 system with libcurl 7.29.0with async rest_get. 
Some more questions:


- does the following crash your system? If not, please detail the nature 
of your HTTP transfer that's causing the crash (server location and a 
.pcap of a successful curl would be nice).


async(rest_get("https://example.com;, "$var(body)"), resume_route);

- are you using any custom patches for rest_client? I suggest we only 
use the 2.2.3 tag code when debugging this issue, from now on


Regards,

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

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 08.03.2017 18:05, Ramachandran, Agalya (Contractor) wrote:


Hi Liviu,

You got time to reproduce this issue? If you need any help towards it 
let me know.


Regards,
Agalya

*From:*Ramachandran, Agalya (Contractor)
*Sent:* Thursday, March 02, 2017 12:16 PM
*To:* users@lists.opensips.org
*Subject:* RE: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 
2.2.3 and 1.11.10


Hi Liviu,

My answers inline. Recompiled with QM_MALLOC / DBG_MALLOC flags enabled.

- async rest function you are using (get / post) – Am using PUT, tried 
POST too. Both cases it crashes.


After restarting OpenSIPS, output of “opensipsctl fifo get_statistics 
shmem: pkmem” is attached here with this email.


Regards,
Agalya

*From:*Users [mailto:users-boun...@lists.opensips.org] *On Behalf Of 
*Liviu Chircu

*Sent:* Thursday, March 02, 2017 11:17 AM
*To:* users@lists.opensips.org 
*Subject:* Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 
2.2.3 and 1.11.10


Hi Agalya,

Yes, let's start dissecting it over there. Since the crash is in 
libcurl, I need the following info in the report, for starters:


- OS version (I understand libcurl is 7.29.0,maybe I can attempt to 
reproduce)


- async rest function you are using (get / post)

- output of "opensipsctl fifo get_statistics shmem: pkmem:", right 
after you start OpenSIPS


Also, are you able to recompile OpenSIPS with both QM_MALLOC / 
DBG_MALLOC flags enabled? It will speed up our debugging. You can 
select these under the compile flags menu, once you run the "make 
menuconfig" build configurator.


Regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
OpenSIPS Summit May 2017 Amsterdam
   http://www.opensips.org/events/Summit-2017Amsterdam.html

On 02.03.2017 17:27, Ramachandran, Agalya (Contractor) wrote:

Hi Liviu,

I have applied your fix with commit
id(df6a9a9bc3f7c65165639a9c88a4359698d0e5b8),retested it still am
facing the same issue.

Should I raise for the defect in
https://github.com/OpenSIPS/opensips/issues ?

Regards,
Agalya



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

[OpenSIPS-Users] Opensips Postgresql Seq Create Error

[Nathaniel L. Keeling III]

I am getting this error when initially creating the opensips database. I
am using Opensips v 2.2 with Postgresql 9.2.6 on Centos 7

[root@sip_core_proxy sbin]# ./opensipsdbctl create
PGSQL password for postgres:
INFO: creating database opensips ...
*ERROR:  relation "location_id_seq" does not exist**
**ERROR:  relation "tls_mgm_id_seq" does not exist*
INFO: Core OpenSIPS tables successfully created.

Thanks

Nathaniel L Keeling


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