-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Closed
Labels
defectcategory: a defect or misbehaviourcategory: a defect or misbehaviour
Description
What type of defect/bug is this?
Unexpected behaviour (obvious or verified by project member)
How can the issue be reproduced?
How can the issue be reproduced?
By providing the scenario that makes the fr_packet_list_socket_add function in packet.c return false, such as open too many sockets by sending High TPS load to home servers.
After some sockets got closed due to marking related home servers dead, no new socket is able to be opened.
I think the root cause is the following code which marks the proxy_no_new_sockets = true; .
freeradius-server/src/main/process.c
Lines 2623 to 2635 in fcafe4d
| if (!fr_packet_list_socket_add(proxy_list, this->fd, | |
| sock->proto, | |
| #ifdef WITH_RADIUSV11 | |
| sock->radiusv11, | |
| #endif | |
| &sock->other_ipaddr, sock->other_port, | |
| this)) { | |
| #ifdef HAVE_PTHREAD_H | |
| proxy_no_new_sockets = true; | |
| #endif | |
| talloc_free(this); | |
| PTHREAD_MUTEX_UNLOCK(&proxy_mutex); |
So in
freeradius-server/src/main/process.c
Lines 2607 to 2609 in fcafe4d
| #ifdef HAVE_PTHREAD_H | |
| if (proxy_no_new_sockets) break; | |
| #endif |
if will breaks the loop to try to open any new socket even if it is available.
Log output from the FreeRADIUS daemon
n/aRelevant log output from client utilities
No response
Backtrace from LLDB or GDB
Metadata
Metadata
Assignees
Labels
defectcategory: a defect or misbehaviourcategory: a defect or misbehaviour