Hi Henning,

Right you are.

Beta trial system with low traffic running on 3 listening interfaces in udp&tcp&tls + one alternative port in UDP&TCP on public interfaces. Considering children=4, that makes indeed a lot of processes in total.

The 'problem' should go away by itself once this goes in production. Meanwhile, I'll look into familiarizing myself with the 'socket_workers=' settings which I just discovered.

Thanks.

On Sun, Oct 7, 2018 at 4:31 PM Henning Westerholt <hw@kamailio.org> wrote:
Am Montag, 1. Oktober 2018, 05:25:28 CEST schrieb Sergiu Pojoga:
> I'm trying to understand why some Kamailio processes become Connor MacLeod
> and go to live forever causing high # of aborted connections.
>
> While watching in time over *SHOW PROCESSLIST*, some 12 kamailio
> connections in *SLEEP* state, most of them are reused over time (time value
> gets reset). However, a select few go on to SLEEP forever for as much as
> the mysql's *wait_timeout* allows them to. Default was 28800 sec, that's
> how long they lived. If I lower this to say 600 sec, even higher abort rate
> is observed.
>
> I suppose my questions are:
>
>    1. Is this normal to have so many SLEEPing connections?
>    2. What is the recommended MySQL *wait_timeout* value under Kamailio?
>    3. Any other suggestions as to why such a high rate of aborted
>    connections?

Hello Sergiu,

it depends a bit on your configuration - but one reason could be that you
start n kamailio processes for each of your local network interfaces. And if
you don't see any SIP traffic on this interfaces, then the Kamailio will sleep
and you can see this aborted connections.

You should be able to check this with e.g. netstat and ps.

Best regards,

Henning

--
Henning Westerholt - https://skalatan.de/blog/
Kamailio security assessment - https://skalatan.de/de/assessment