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]:
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
>
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
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
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
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,
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:
>
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
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
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
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...
>
> #
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
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
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,
14 matches
Mail list logo