Hi Yuri,
Could you give this patch a try? it should fix the blocking you
experience (it should apply on 3.2 too).
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS Summit 27-30 Sept 2022, Athens
https://www.opensips.org/events/Summit-2022Athens/
On 9/7/22 2:54 PM, Bogdan-Andrei Iancu wrote:
Hi Yury,
Thanks for the details info here - let me do a review of some code and
run some tests, as at this point I have a good idea on the direction
to dig into.
I will update here.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS Summit 27-30 Sept 2022, Athens
https://www.opensips.org/events/Summit-2022Athens/
On 9/6/22 11:24 AM, Yury Kirsanov wrote:
Hi Bogdan,
Yes, I'm listening on all types of sockets including UDP, TCP and TLS
on the outside public interface and then forward traffic into
internal LAN via UDP only.
Previously it was getting stuck quite easily, now I had to wait for a
while before this actually happened. I've routed part of my customers
to this server to obtain this result so I will have to do that again.
As soon as I see one of the processes stuck I'll dot the trap command
and send you all the details including processes load, ps output and
so on.
For now I had to switch autoscaling off and just create many
listeners. Do I understand correctly that I need to restart OpenSIPS
in order to apply autoscaling profiles and reload-routes is not
sufficient?
Also, do I need separate UDP profiles for public and private
interfaces? And do I need to apply autoscaling profile just to a
socket or I need to specify udp or tcp_workers with autoscaler too?
Thanks and best regards,
Yury.
On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, <bog...@opensips.org
<mailto:bog...@opensips.org>> wrote:
Hi Yury,
Thanks for the info. I see that the stuck process (24) is an
auto-scalled one (based on its id). Do you have SIP traffic from
UDP to TCP or doing some HEP capturing for SIP ? I saw a recent
similar report where a UDP auto-scalled worked got stuck when
trying to do some communication with the TCP main/manager process
(in order to handle a TCP operation).
BTW, any chance to do a "opensips-cli -x trap" when you have that
stuck process, just to see where is it stuck? and is it hard to
reproduce? as I may ask you to extract some information from the
running process....
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com <https://www.opensips-solutions.com>
OpenSIPS Summit 27-30 Sept 2022, Athens
https://www.opensips.org/events/Summit-2022Athens/
<https://www.opensips.org/events/Summit-2022Athens/>
On 9/3/22 6:54 PM, Yury Kirsanov wrote:
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
diff --git a/net/net_tcp.c b/net/net_tcp.c
index fff9aab4a..b6edce32f 100644
--- a/net/net_tcp.c
+++ b/net/net_tcp.c
@@ -1652,13 +1652,13 @@ static void tcp_main_server(void)
* processes (get fd, new connection a.s.o)
* NOTE: we add even the socks for the inactive/unfork processes - the
* socks are already created, but the triggering is from proc to
- * main, having them into reactor is harmless - thye will never
+ * main, having them into reactor is harmless - they will never
* trigger as there is no proc on the other end to write us */
for (n=1; n<counted_max_processes; n++) {
/* skip myslef (as process) and -1 socks (disabled)
(we can't have 0, we never close it!) */
- if (n!=process_no && pt[n].unix_sock>0)
- if (reactor_add_reader( pt[n].unix_sock, F_TCP_WORKER,
+ if (n!=process_no && pt[n].tcp_socks_holder[0]>0)
+ if (reactor_add_reader( pt[n].tcp_socks_holder[0], F_TCP_WORKER,
RCT_PRIO_PROC, &pt[n])<0){
LM_ERR("failed to add process %d (%s) unix socket "
"to the fd list\n", n, pt[n].desc);
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
