Le Tue, 24 Nov 2015 09:49:36 -0600,
Anthony Messina a écrit :
> When the close_expired_tcp modparam was disabled, Kamailio never
> displayed this warning and continued to process all TLS connections
> from 2015-11-19 through 2015-11-23, when I re-enabled the
> close_expired_tcp modparam for
Le Tue, 24 Nov 2015 09:49:36 -0600,
Anthony Messina a écrit :
> After having re-enabled the close_expired_tcp modparam, Kamailio
> made it about 12hours before giving the following warning and
> blocking new TLS connections again:
>
> ERROR: tls [tls_server.c:189]: tls_complete_init(): tls: ssl
After having re-enabled the close_expired_tcp modparam, Kamailio made
it about 12hours before giving the following warning and blocking new
TLS connections again:
ERROR: tls [tls_server.c:189]: tls_complete_init(): tls: ssl bug #1491
workaround: not enough memory for safe operation: 8870536
I have re-enabled the close_expired_tcp modparam and will report back when I
have results. Thanks Camille. -A
--
Anthony - https://messinet.com/
On November 23, 2015 3:46:55 AM CST, Camille Oudot
wrote:
>Le Sun, 22 Nov 2015 15:22:06 -0600,
>Anthony Messina a écrit :
>
>> I did tow things on
Le Sun, 22 Nov 2015 15:22:06 -0600,
Anthony Messina a écrit :
> I did tow things on 2015-11-19 which seem to have (at least
> temporarily) resolved this issue:
>
> 1. Upgraded to git master@b056aed
>
> 2. Commented out #modparam("usrloc", "close_expired_tcp", 1) based on
> http://lists.sip-rou
I did tow things on 2015-11-19 which seem to have (at least temporarily)
resolved this issue:
1. Upgraded to git master@b056aed
2. Commented out #modparam("usrloc", "close_expired_tcp", 1) based on
http://lists.sip-router.org/pipermail/sr-users/2015-November/090733.html
-A
On Wednesday, Novem
I was just letting you know how I build it, but yes, I will test with just the
bare master branch this weekend. After a restart, this issue takes a few
hours to happen, making it difficult to reproduce in testing. -A
On Wednesday, November 18, 2015 10:30:16 AM Daniel-Constantin Mierla wrote:
>
It is not clear how what sources you are using, what does it mean
'latest release tarball' -- version 4.3.3? Then did you take all the
patches from master since version 4.3.0?
I tested master with 2 registrations over TLS sent by sipp, but I
couldn't spot any leak there.
Can you test with bar
Sorry for the delay, I just got home from my $PAYINGJOB. And thanks a lot for
helping figure this out.
I build Kamailio RPMs from the latest release tarball, with the changes
between the release and git master applied via patch, but here is the version
output:
# kamailio -v
version: kamailio
Looking at the logs of last commits, I couldn't spot the change that
would add the leak.
What is the exact version you are running (kamailio -v)?
Are you using any of the functions exported by tcpops?
Cheers,
Daniel
On 17/11/15 15:24, Anthony Messina wrote:
> I wish that were the case...
>
> #
I wish that were the case...
# kamcmd core.tcp_info
{
readers: 2
max_connections: 2048
max_tls_connections: 2048
opened_connections: 0
opened_tls_connections: 0
write_queued_bytes: 0
}
# kamcmd tls.info
{
max_connections: 2048
opened
Looks like a lot of connections being open, can you get the output for:
kamcmd core.tcp_info
kamcmd tls.info
Cheers,
Daniel
On 17/11/15 14:59, Anthony Messina wrote:
> Attached. -A
>
> On Tuesday, November 17, 2015 02:50:21 PM Daniel-Constantin Mierla wrote:
>> Can you run the following comman
Attached. -A
On Tuesday, November 17, 2015 02:50:21 PM Daniel-Constantin Mierla wrote:
> Can you run the following commands:
>
> kamcmd cfg.set_now_int core memlog 1
> kamcmd corex.shm_summary
>
> Then grab the log messages from syslog related to shared memory summary
> and send them over here.
>
Can you run the following commands:
kamcmd cfg.set_now_int core memlog 1
kamcmd corex.shm_summary
Then grab the log messages from syslog related to shared memory summary
and send them over here.
Cheers,
Daniel
On 17/11/15 14:31, Anthony Messina wrote:
> After I reported last night, I restarted
After I reported last night, I restarted Kamailio and even though the 5 UACs
did nothing but ensure they had a registration overnight, this morning the
issue has recurred. The following is the output you requested. Not sure how
the memory is being used up by Kamailio.
# kamctl stats shmem
shm
As you are using the master branch (development), do you run latest version?
Can you look at available shared memory?
kamctl stats shmem
Check it over time and see if the free memory is decreasing.
Cheers,
Daniel
On 17/11/15 00:44, Anthony Messina wrote:
> I have noticed the following issue wh
I have noticed the following issue which began with builds somewhere between
git master commits bff0a08 and 6173ef7. I did not see this issue with my
previous builds and haven't been able to pin down the problem, which is why I
haven't formally filed a bug.
Any help or guidance is appreciated,
17 matches
Mail list logo
