[SR-Users] Kamailio stop to process incoming SIP traffic via TCP.

Sergey Safarov s.safarov at gmail.com
Wed Feb 27 12:49:08 CET 2019


I think need to increase LimitNOFILE in systemd file
https://www.freedesktop.org/software/systemd/man/systemd.exec.html

[Service]
LimitNOFILE=999999
.....

Sergey

ср, 27 февр. 2019 г., 14:27 Ivaylo Markov <ivo at schupen.net>:

> Hello,
>
> I believe this issue is related -
> https://github.com/kamailio/kamailio/issues/1172. We encountered the
> problem before and the solution is to link kamailio-tls-modules with
> libssl1.0.X instead of libssl1.1.
> On 27/02/2019 13:23, Jurijs Ivolga wrote:
>
> Hi,
>
> Just to add that in my case I had a problem when after some period of time
> with a lot of TLS clients(100k+) I got a lot of TCP connections in
> CLOSE_WAIT state. When connections in CLOSE_WAIT state hit more then 1k,
> then kamailio stopped to receive traffic via TLS, nevertheless UDP at same
> time worked fine. From my point of view it looked like there was issue
> somewhere on Linux side, cause Kamailio never got anything... At least this
> is what I remember... I still plan to work on it someday. :) And if I will
> find out, I'll let you know.
>
> Jurijs
>
>
> On Wed, Feb 27, 2019 at 1:13 PM Kristijan Vrban <vrban.lkml at gmail.com>
> wrote:
>
>> when is strace to the kamailio process that is attached to the tcp
>> port. it get sporadic this:
>>
>> [], 46, 5000)            = 0
>> epoll_wait(17, [{EPOLLIN, {u32=2692971064 <(269)%20297-1064>,
>> u64=139924137540152}}], 46, 5000) = 1
>> accept(14, {sa_family=AF_INET, sin_port=htons(59766),
>> sin_addr=inet_addr("xxx.xx.xxx.xxx")}, [28->16]) = 275
>> fcntl(275, F_GETFL)                     = 0x2 (flags O_RDWR)
>> fcntl(275, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
>> epoll_ctl(17, EPOLL_CTL_ADD, 275, {EPOLLIN|EPOLLRDHUP,
>> {u32=2692977328 <(269)%20297-7328>, u64=139924137546416}}) = 0
>> epoll_wait(17, [{EPOLLIN, {u32=2692977328 <(269)%20297-7328>,
>> u64=139924137546416}}], 47, 5000) = 1
>> epoll_ctl(17, EPOLL_CTL_DEL, 275, 0x7ffdae44ee4c) = 0
>> recvmsg(53, {msg_namelen=0}, MSG_DONTWAIT) = -1 EAGAIN (Resource
>> temporarily unavailable)
>> recvfrom(56, 0x7ffdae44ed90, 16, MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN
>> (Resource temporarily unavailable)
>> sendmsg(56, {msg_name=NULL, msg_namelen=0,
>> msg_iov=[{iov_base="\210ku\230B\177\0\0", iov_len=8}], msg_iovlen=1,
>> msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET,
>> cmsg_type=SCM_RIGHTS, cmsg_data=[275]}], msg_controllen=20,
>> msg_flags=0}, 0) = 8
>> epoll_wait(17,
>>
>> But that's all, no further processing by kamailio.
>>
>> Am Mi., 27. Feb. 2019 um 11:53 Uhr schrieb Kristijan Vrban
>> <vrban.lkml at gmail.com>:
>> >
>> > Hi kamailios,
>> >
>> > i have a creepy situation with v5.2.1 stable Kamilio. After a day or
>> > so, Kamailio stop to process incoming SIP traffic via TCP. The
>> > incoming TCP network packages get TCP-ACK from the OS (Debian 9,
>> > 4.18.0-15-generic-Linux) but Kamailio does not show any processing for
>> > the SIP-Traffic incoming via TCP. No logs, nothing. While traffic via
>> > UDP is working just totally fine.
>> >
>> > When i look via command "netstat -ntp" is see, that the Recv-Q get
>> > bigger and bigger. e.g.:
>> >
>> > Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program
>> > name tcp 4566 0 172.17.217.12:5060 xxx.xxx.xxx.xxx:57252 ESTABLISHED
>> > 31347/kamailio
>> >
>> > After Kamailio restart, all is working fine again for a day. We have
>> > maybe 10-20 devices online via TCP and low call volume (1-2 call per
>> > minute). The only settings for tcp we have is "tcp_delayed_ack=no"
>> >
>> > How to could we debug this situation? Again, no error, no warings in
>> > the log. Just nothing.
>> >
>> > Kristijan
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190227/24e36988/attachment.html>


More information about the sr-users mailing list