radiusd crashes. ASSERT FAILED src/main/threads.c[794]
Hi, Freradius 3.2.7, Ubuntu 24.04.2 LTS How to solve this problem? Mon May 19 09:17:25 2025 : Error: (11542) Ignoring duplicate packet from client dhcp port 68 - ID: 3396190219 due to unfinished request in component post-auth module dhcplog Mon May 19 09:17:25 2025 : Error: Received conflicting packet from client dhcp port 68 - ID: 734446164 due to unfinished request in module dhcplog. Giving up on old request. Mon May 19 09:17:25 2025 : Error: Received conflicting packet from client dhcp port 68 - ID: 734446164 due to unfinished request in module <queue>. Giving up on old request. Mon May 19 09:17:25 2025 : Error: ASSERT FAILED src/main/threads.c[794]: request->child_state == REQUEST_QUEUED CAUGHT SIGNAL: Aborted Backtrace of last 6 frames: /usr/local/radius3/lib/libfreeradius-radius.so(fr_fault+0x139)[0x71d729f4b3d6] /usr/local/radius3/lib/libfreeradius-server.so(rad_assert_fail+0x4d)[0x71d729fb9591] /usr/local/radius3/sbin/radiusd(+0x4cf9e)[0x63cb44340f9e] /usr/local/radius3/sbin/radiusd(+0x4d275)[0x63cb44341275] /lib/x86_64-linux-gnu/libc.so.6(+0x9caa4)[0x71d72969caa4] /lib/x86_64-linux-gnu/libc.so.6(+0x129c3c)[0x71d729729c3c] Calling: gdb -silent -x /usr/local/radius3/etc/raddb/panic.gdb /usr/local/radius3/sbin/radiusd 3026728 2>&1 | tee /usr/local/radius3/var/log/radius/gdb-radiusd-3026728.log Temporarily setting PR_DUMPABLE to 1 Mon May 19 09:17:25 2025 : WARNING: (11548) WARNING: Module dhcplog(rlm_sql) became unblocked Mon May 19 09:17:25 2025 : Error: (11571) Ignoring duplicate packet from client dhcp port 67 - ID: 3795885685 due to unfinished request in component <core> module Resetting PR_DUMPABLE to 0 Panic action exited with 0 _EXIT(0) CALLED src/lib/debug.c[811] regards, Sergey Kodentsev -- С уважением, Сергей Коденцев, Технический центр, ООО ИК "Информсвязь-Черноземье"
On May 19, 2025, at 8:52 AM, Sergei Kodentsev <sergk@ic.vrn.ru> wrote:
On 19.05.2025 16:28, Alan DeKok wrote:
On May 19, 2025, at 7:32 AM, Sergei Kodentsev <sergk@ic.vrn.ru> wrote: For now, delete the assertion and recompile. We've pushed a fix to GitHub, and the fix will be in the next release.
How to delete assertion?
Edit the source code. Alan DeKok.
Hi, radiusd is crashed Wed May 21 12:15:21 2025 : Error: ASSERT FAILED src/main/threads.c[793]: request->magic == REQUEST_MAGIC # git branch master v3.0.x * v3.2.x # git log commit 28a1e473767819ac73b066df303df7fda5382081 (HEAD -> v3.2.x, origin/v3.2.x) Author: Alan T. DeKok <aland@freeradius.org> Date: Mon May 19 14:26:58 2025 -0500 if we're not using the packet contents, don't call rad_recv() ................................. On 19.05.2025 17:11, Alan DeKok wrote:
On May 19, 2025, at 8:52 AM, Sergei Kodentsev <sergk@ic.vrn.ru> wrote:
On 19.05.2025 16:28, Alan DeKok wrote:
On May 19, 2025, at 7:32 AM, Sergei Kodentsev <sergk@ic.vrn.ru> wrote: For now, delete the assertion and recompile. We've pushed a fix to GitHub, and the fix will be in the next release.
regards, Sergey Kodentsev
On 21.05.2025 15:14, Alan DeKok wrote:
Hm... what's the rest of the debug log?
Wed May 21 12:15:21 2025 : Error: (1707753) Ignoring duplicate packet from client dhcp port 67 - ID: 45241580 due to unfinished request in component post-auth module dhcplog Wed May 21 12:15:21 2025 : Error: (1707764) Ignoring duplicate packet from client dhcp port 67 - ID: 336510328 due to unfinished request in component post-auth module dhcpstaticnd Wed May 21 12:15:21 2025 : Error: (1707772) Ignoring duplicate packet from client dhcp port 68 - ID: 1952515869 due to unfinished request in component post-auth module dhcpstaticnd Wed May 21 12:15:21 2025 : Error: (1707786) Ignoring duplicate packet from client dhcp port 67 - ID: 4197260409 due to unfinished request in component <core> module Wed May 21 12:15:21 2025 : Error: (1707833) Ignoring duplicate packet from client dhcp port 68 - ID: 1061430653 due to unfinished request in component <core> module Wed May 21 12:15:21 2025 : Error: (1707848) Ignoring duplicate packet from client dhcp port 68 - ID: 140491380 due to unfinished request in component <core> module <queue> Wed May 21 12:15:21 2025 : Error: (1707853) Ignoring duplicate packet from client dhcp port 67 - ID: 1492502848 due to unfinished request in component post-auth module dhcplog Wed May 21 12:15:21 2025 : Error: Received conflicting packet from client dhcp port 68 - ID: 1286895697 due to unfinished request in module dhcpstaticnd. Giving up on old request. Wed May 21 12:15:21 2025 : Error: Received conflicting packet from client dhcp port 68 - ID: 1286895697 due to unfinished request in module <queue>. Giving up on old request. Wed May 21 12:15:21 2025 : Error: ASSERT FAILED src/main/threads.c[793]: request->magic == REQUEST_MAGIC Wed May 21 12:15:21 2025 : WARNING: (1707865) WARNING: Module dhcpstaticnd(rlm_sql) became unblocked Wed May 21 12:15:21 2025 : Error: (1707905) Ignoring duplicate packet from client dhcp port 68 - ID: 3004861544 due to unfinished request in component post-auth module Wed May 21 12:15:21 2025 : Error: Received conflicting packet from client dhcp port 68 - ID: 961122431 due to unfinished request in module . Giving up on old request. Wed May 21 12:15:21 2025 : Error: Received conflicting packet from client dhcp port 68 - ID: 492045777 due to unfinished request in module dhcproute. Giving up on old request. Wed May 21 12:15:21 2025 : WARNING: (1707913) WARNING: Module dhcproute(rlm_sql) became unblocked Wed May 21 12:15:21 2025 : Error: (1707919) Ignoring duplicate packet from client dhcp port 67 - ID: 632528912 due to unfinished request in component post-auth module dhcpstaticnd
On May 21, 2025, at 7:23 AM, Sergei Kodentsev <sergk@ic.vrn.ru> wrote:
On 21.05.2025 15:14, Alan DeKok wrote:
Hm... what's the rest of the debug log?
Wed May 21 12:15:21 2025 : Error: (1707753) Ignoring duplicate packet from client dhcp port 67 - ID: 45241580 due to unfinished request in component post-auth module dhcplog Wed May 21 12:15:21 2025 : Error: (1707764) Ignoring duplicate packet from client dhcp port 67 - ID: 336510328 due to unfinished request in component post-auth module dhcpstaticnd
I'll take a look and see if I can reproduce this. But the underlying issue is that those modules are slow, and are blocking the server. It's possible to update the server so it doesn't hit this assertion, but the server will still be unable to make progress. It won't process packets, and it won't respond to packets. The only fix is to make sure that modules do not block the server.
Wed May 21 12:15:21 2025 : WARNING: (1707865) WARNING: Module dhcpstaticnd(rlm_sql) became unblocked ... Wed May 21 12:15:21 2025 : WARNING: (1707913) WARNING: Module dhcproute(rlm_sql) became unblocked Wed May 21 12:15:21 2025 : Error: (1707919) Ignoring duplicate packet from client dhcp port 67 - ID: 632528912 due to unfinished request in component post-auth module dhcpstaticnd
The SQL databases which these modules are querying is taking 5-30 seconds to respond. No amount of poking FreeRADIUS will make the SQL database faster. Fix the SQL database so that it replies within a second, ideally much less. FreeRADIUS will then be able to operate normally. Alan DeKok.
Hi, On 23.05.2025 01:06, Alan DeKok via Freeradius-Users wrote:
I'll take a look and see if I can reproduce this. But the underlying issue is that those modules are slow, and are blocking the server.
It's possible to update the server so it doesn't hit this assertion, but the server will still be unable to make progress. It won't process packets, and it won't respond to packets.
The only fix is to make sure that modules do not block the server. Thank you. In my opinion, an unanswered packet is better than a radiusd crash.
The SQL databases which these modules are querying is taking 5-30 seconds to respond. No amount of poking FreeRADIUS will make the SQL database faster.
Fix the SQL database so that it replies within a second, ideally much less. FreeRADIUS will then be able to operate normally.
I'll try to optimize the sql database. redards, Sergey Kodentsev.
Hi,
The SQL databases which these modules are querying is taking 5-30 seconds to respond. No amount of poking FreeRADIUS will make the SQL database faster.
Fix the SQL database so that it replies within a second, ideally much less. FreeRADIUS will then be able to operate normally.
Alan DeKok. MariaDB 10.6.21 database server.
database load here - https://drive.google.com/file/d/1eN-WN-DNikfmCDQV0KdgbYOAUO2lJQ6B/view?usp=s... Every 0.5 sec execution from 2025-05-23 14:30:47.349429 to 2025-05-23 14:35:50.900787 SELECT info,time_ms FROM information_schema.processlist pr WHERE command != 'Sleep' AND db='raddbdhcp' Result here - https://drive.google.com/file/d/1nkMYXL-BefEcmtTlZk2XL6Pd2KYZwsnQ/view?usp=s... Maximum query execution time 230.654 milliseconds. During this time, 47 warnings become unblocked in freeradius logs - https://drive.google.com/file/d/1bbQ8_zLdreW-_pXXccc3SJ8bzZr2IJqR/view?usp=s... Why? redards, Sergey Kodentsev
On May 23, 2025, at 7:17 AM, Sergei Kodentsev <sergk@ic.vrn.ru> wrote:
database load here - https://drive.google.com/file/d/1eN-WN-DNikfmCDQV0KdgbYOAUO2lJQ6B/view?usp=s... Every 0.5 sec execution from 2025-05-23 14:30:47.349429 to 2025-05-23 14:35:50.900787 SELECT info,time_ms FROM information_schema.processlist pr WHERE command != 'Sleep' AND db='raddbdhcp' Result here - https://drive.google.com/file/d/1nkMYXL-BefEcmtTlZk2XL6Pd2KYZwsnQ/view?usp=s... Maximum query execution time 230.654 milliseconds. During this time, 47 warnings become unblocked in freeradius logs - https://drive.google.com/file/d/1bbQ8_zLdreW-_pXXccc3SJ8bzZr2IJqR/view?usp=s... Why?
Because the database is slow. It doesn't matter what the tests say. The SQL database is taking 5-30 seconds to reply to FreeRADIUS. Your choices are: a) fix the database and solve the problem b) don't fix the database, and spend days trying to figure out how to "fix" FreeRADIUS when the problem is actually SQL. Pick one. Alan DeKok.
Hi, On 23.05.2025 17:08, Alan DeKok via Freeradius-Users wrote:
Because the database is slow.
It doesn't matter what the tests say. The SQL database is taking 5-30 seconds to reply to FreeRADIUS.
These are not tests. This is a query about running database processes when freeradius is running. Sergey Kodentsev.
On May 23, 2025, at 9:26 AM, Sergei Kodentsev <sergk@ic.vrn.ru> wrote:
On 23.05.2025 17:08, Alan DeKok via Freeradius-Users wrote:
Because the database is slow.
It doesn't matter what the tests say. The SQL database is taking 5-30 seconds to reply to FreeRADIUS.
These are not tests. This is a query about running database processes when freeradius is running.
You are checking high-level database stats, and doing test queries. They don't matter. This has been an issue for decades now. People blame FreeRADIUS because the database is slow, and then refuse to fix the database. This is not the first time this issue has come up. It's not even the 100'th time it's come up. The problem of "SQL module became unblocked" is ALWAYS that the SQL database is slow. If you think that the slow database problem is FreeRADIUS, then you have the source code to FreeRADIUS: go fix it. But whatever you do, it's not at productive to ask people for help, and then argue with the answers that they give. If you're not going to listen to advice, then there's no need to ask questions. Go fix the database. Nothing else will solve the problem. I've said that _hundreds_ of times. Alan DeKok.
Hi, 23.05.2025 17:50, Alan DeKok via Freeradius-Users пишет:
You are checking high-level database stats, and doing test queries. They don't matter.
I repeat, I do not make test queries. I look at the execution time of real queries from a working freeradius using MariaDB. And this response time differs significantly from what freeradius shows, although it should be the same. Sergey Kodentsev
You are checking high-level database stats, and doing test queries. They don't matter.
I repeat, I do not make test queries. I look at the execution time of real queries from a working freeradius using MariaDB. And this response time differs significantly from what freeradius shows, although it should be the same. Sergey Kodentsev
I’ll make a suggestion, do the SAME queries from the SAME server when there is the SAME load. Anything else is a waste of time when looking at DB performance. Add to this that it could be a wonderful list of issues here are my current favourites when faced with a slow RADIUS (or in fact any high-packet-rate service). Note that some of these only happen when operating at high enough packet rates. Network packet loss, Security tools, Security features like anti-ddos, Too small a network link 1G vs 10G vs 40G depending on size of issue NIC card ring buffers too small NIC settings bad for UDP services (especially interrupt and per-interrupt processing settings) OS buffers too small (or too big) sadly this one depends on what you are looking at. DNS is slow (especially the totally terrible performing proxies that are default for some ‘container’ setups) TLS (needs random numbers is slow because its blocking on /dev/random) Switch port has flooded per-port buffer Firewall is running out of resource (CPU / MEMORY etc) Load-balancer is running out of a resource. DB is running with a socket limit that’s too small DB is running with a process max-connections limit that’s too small Some other process/VM/container is using too much I/O and thus destroying performance Some other process/VM/container is using too much memory causing swapping Not enough resources allocated (servers /cpu/memory/etc). Missing Indexes Crazy expensive query Crazy expensive ‘insert or update’ I know its service diagnosis 101 but you can see not one of these is FreeRADIUS it’s surprisingly rare that it’s actually the FreeRADIUS code itself. So much so I’ll exhaust the external causes before looking too hard at what FreeRADIUS is doing. A. From: Freeradius-Users <freeradius-users-bounces+alister.winfield=sky.uk@lists.freeradius.org> on behalf of Sergey Kodentsev <sergk@ic.vrn.ru> Date: Friday, 23 May 2025 at 17:21 To: freeradius-users@lists.freeradius.org <freeradius-users@lists.freeradius.org> Subject: [EXTERNAL] Re: radiusd crashes. ASSERT FAILED src/main/threads.c[794] Hi, 23.05.2025 17:50, Alan DeKok via Freeradius-Users пишет: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html<http://www.freeradius.org/list/users.html> -------------------------------------------------------------------- This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to phishing@sky.uk. Thank you -------------------------------------------------------------------- Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
That’s not the query that FreeRADIUS is performing, so you are seeing stats that don’t help. Query time is the time from query receipt to query result NOT the overall time which includes connection delays, TLS delays and authentication delays. You are missing. <FR needs to do a query> <Highly likely pool is exhausted so.> Time to resolve hostname of DB Time to connect to DB socket Time for TLS exchange (Assuming encrypted comms). Time to authenticate to DB <Start of Query> THIS IS THE NUMBER YOU HAVE <End of Query> Time for result set to get to the RADIUS server <here FINALLY FR gets to do something with that result> You need the WHOLE time taken A. From: Freeradius-Users <freeradius-users-bounces+alister.winfield=sky.uk@lists.freeradius.org> on behalf of Sergei Kodentsev <sergk@ic.vrn.ru> Date: Tuesday, 27 May 2025 at 10:44 To: freeradius-users@lists.freeradius.org <freeradius-users@lists.freeradius.org> Subject: [EXTERNAL] Re: radiusd crashes. ASSERT FAILED src/main/threads.c[794] Hi,
The SQL databases which these modules are querying is taking 5-30 seconds to respond. No amount of poking FreeRADIUS will make the SQL database faster.
Fix the SQL database so that it replies within a second, ideally much less. FreeRADIUS will then be able to operate normally.
Alan DeKok. MariaDB 10.6.21 database server.
database load here - https://drive.google.com/file/d/1eN-WN-DNikfmCDQV0KdgbYOAUO2lJQ6B/view?usp=sharing<https://drive.google.com/file/d/1eN-WN-DNikfmCDQV0KdgbYOAUO2lJQ6B/view?usp=sharing> Every 0.5 sec execution from 2025-05-23 14:30:47.349429 to 2025-05-23 14:35:50.900787 SELECT info,time_ms FROM information_schema.processlist pr WHERE command != 'Sleep' AND db='raddbdhcp' Result here - https://drive.google.com/file/d/1nkMYXL-BefEcmtTlZk2XL6Pd2KYZwsnQ/view?usp=sharing<https://drive.google.com/file/d/1nkMYXL-BefEcmtTlZk2XL6Pd2KYZwsnQ/view?usp=sharing> Maximum query execution time 230.654 milliseconds. During this time, 47 warnings become unblocked in freeradius logs - https://drive.google.com/file/d/1bbQ8_zLdreW-_pXXccc3SJ8bzZr2IJqR/view?usp=sharing<https://drive.google.com/file/d/1bbQ8_zLdreW-_pXXccc3SJ8bzZr2IJqR/view?usp=sharing> Why? redards, Sergey Kodentsev - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html<http://www.freeradius.org/list/users.html> -------------------------------------------------------------------- This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to phishing@sky.uk. Thank you -------------------------------------------------------------------- Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
Hi, This is the request that radius performs. TLS is not used. The connection is taken from the pool to locality Authentication delays are not a database problem. <Start of Query> THIS IS THE NUMBER YOU HAVE <End of Query> Alan says that this is where the problem is. Redards, Sergey Kodentsev. On 27.05.2025 12:52, Winfield, Alister (Senior Solutions Architect) via Freeradius-Users wrote:
That’s not the query that FreeRADIUS is performing, so you are seeing stats that don’t help. Query time is the time from query receipt to query result NOT the overall time which includes connection delays, TLS delays and authentication delays.
You are missing.
<FR needs to do a query> <Highly likely pool is exhausted so.> Time to resolve hostname of DB Time to connect to DB socket Time for TLS exchange (Assuming encrypted comms). Time to authenticate to DB
<Start of Query> THIS IS THE NUMBER YOU HAVE <End of Query>
Time for result set to get to the RADIUS server <here FINALLY FR gets to do something with that result>
You need the WHOLE time taken
Last attempt, assuming the connection pool is full and thus no connection delays causing issues. Take your ‘average response time in seconds’ and max_pool_size (max_pool_size / Average_response_time of DB) = Max RADIUS rate possible per second. This is the absolute maximum rate of RADIUS replies per second.. (assumes zero other delays). Increase the number of DB connections and/or reduce average response time until this is greater than the expected RADIUS peek rate. Remembering that more connections will likely increase the response time. Alister From: Freeradius-Users <freeradius-users-bounces+alister.winfield=sky.uk@lists.freeradius.org> on behalf of Sergei Kodentsev <sergk@ic.vrn.ru> Date: Tuesday, 27 May 2025 at 11:30 To: freeradius-users@lists.freeradius.org <freeradius-users@lists.freeradius.org> Subject: Re: [EXTERNAL] Re: radiusd crashes. ASSERT FAILED src/main/threads.c[794] Hi, This is the request that radius performs. TLS is not used. The connection is taken from the pool to locality Authentication delays are not a database problem. <Start of Query> THIS IS THE NUMBER YOU HAVE <End of Query> Alan says that this is where the problem is. Redards, Sergey Kodentsev. On 27.05.2025 12:52, Winfield, Alister (Senior Solutions Architect) via Freeradius-Users wrote:
That’s not the query that FreeRADIUS is performing, so you are seeing stats that don’t help. Query time is the time from query receipt to query result NOT the overall time which includes connection delays, TLS delays and authentication delays.
You are missing.
<FR needs to do a query> <Highly likely pool is exhausted so.> Time to resolve hostname of DB Time to connect to DB socket Time for TLS exchange (Assuming encrypted comms). Time to authenticate to DB
<Start of Query> THIS IS THE NUMBER YOU HAVE <End of Query>
Time for result set to get to the RADIUS server <here FINALLY FR gets to do something with that result>
You need the WHOLE time taken
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html<http://www.freeradius.org/list/users.html> Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
Hi, On 27.05.2025 14:52, Winfield, Alister (Senior Solutions Architect) via Freeradius-Users wrote:
Last attempt, assuming the connection pool is full and thus no connection delays causing issues.
Connection pool is not full. # cat sel SELECT `ID`, `USER`, `HOST`, `DB`, `COMMAND`, `TIME`, `STATE`, `TIME_MS`, `STAGE`, `MAX_STAGE` FROM `information_schema`.`PROCESSLIST` WHERE db = 'raddbdhcp' AND USER = 'raduser' AND HOST = 'localhost' ORDER BY TIME_MS DESC LIMIT 10; # mysql -u raduser -pradpass raddbdhcp < sel ID USER HOST DB COMMAND TIME STATE TIME_MS STAGE MAX_STAGE 23031 raduser localhost raddbdhcp Sleep 2216 NULL 2216113.858 0 0 23182 raduser localhost raddbdhcp Sleep 2216 NULL 2216017.958 0 0 23183 raduser localhost raddbdhcp Sleep 2216 NULL 2216017.365 0 0 23184 raduser localhost raddbdhcp Sleep 2216 NULL 2216016.864 0 0 23185 raduser localhost raddbdhcp Sleep 2216 NULL 2216016.252 0 0 23186 raduser localhost raddbdhcp Sleep 2216 NULL 2216015.731 0 0 23371 raduser localhost raddbdhcp Sleep 0 NULL 373.294 0 0 23435 raduser localhost raddbdhcp Sleep 0 NULL 372.700 0 0 23420 raduser localhost raddbdhcp Sleep 0 NULL 371.557 0 0 23434 raduser localhost raddbdhcp Sleep 0 NULL 370.378 0 0
Take your ‘average response time in seconds’ and max_pool_size
How to find out 'average response time in seconds' ? Sergey Kodentsev
I give up there isn’t enough time to coach people to do trivial admin/diagnostic tasks. The hints should be enough to solve this but it requires that you know your own systems and how to use and diagnose them rather than taking on trust that they are measuring the ‘whole truth’ from one single metric. A. From: Freeradius-Users <freeradius-users-bounces+alister.winfield=sky.uk@lists.freeradius.org> on behalf of Sergei Kodentsev <sergk@ic.vrn.ru> Date: Tuesday, 27 May 2025 at 14:16 To: freeradius-users@lists.freeradius.org <freeradius-users@lists.freeradius.org> Subject: Re: [EXTERNAL] Re: radiusd crashes. ASSERT FAILED src/main/threads.c[794] Hi, On 27.05.2025 14:52, Winfield, Alister (Senior Solutions Architect) via Freeradius-Users wrote:
Last attempt, assuming the connection pool is full and thus no connection delays causing issues.
Connection pool is not full. # cat sel SELECT `ID`, `USER`, `HOST`, `DB`, `COMMAND`, `TIME`, `STATE`, `TIME_MS`, `STAGE`, `MAX_STAGE` FROM `information_schema`.`PROCESSLIST` WHERE db = 'raddbdhcp' AND USER = 'raduser' AND HOST = 'localhost' ORDER BY TIME_MS DESC LIMIT 10; # mysql -u raduser -pradpass raddbdhcp < sel ID USER HOST DB COMMAND TIME STATE TIME_MS STAGE MAX_STAGE 23031 raduser localhost raddbdhcp Sleep 2216 NULL 2216113.858 0 0 23182 raduser localhost raddbdhcp Sleep 2216 NULL 2216017.958 0 0 23183 raduser localhost raddbdhcp Sleep 2216 NULL 2216017.365 0 0 23184 raduser localhost raddbdhcp Sleep 2216 NULL 2216016.864 0 0 23185 raduser localhost raddbdhcp Sleep 2216 NULL 2216016.252 0 0 23186 raduser localhost raddbdhcp Sleep 2216 NULL 2216015.731 0 0 23371 raduser localhost raddbdhcp Sleep 0 NULL 373.294 0 0 23435 raduser localhost raddbdhcp Sleep 0 NULL 372.700 0 0 23420 raduser localhost raddbdhcp Sleep 0 NULL 371.557 0 0 23434 raduser localhost raddbdhcp Sleep 0 NULL 370.378 0 0
Take your ‘average response time in seconds’ and max_pool_size
How to find out 'average response time in seconds' ? Sergey Kodentsev - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html<http://www.freeradius.org/list/users.html> Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
On May 27, 2025, at 6:29 AM, Sergei Kodentsev <sergk@ic.vrn.ru> wrote:
Alan says that this is where the problem is.
No. You've misunderstood or ignored just about everything you've been told. What I say "the database is slow", I do NOT mean one tiny piece of the database is the only thing that exists. I mean: * FreeRADIUS starts an SQL query * ... 10 seconds later the SQL query returns * FreeRADIUS logs a message "module became unblocked" The problem isn't FreeRADIUS. Which means that this issue is off topic for the FreeRADIUS list. Stop arguing about it, and go fix the problem. Your next message to the list will either be: a) a message describing what you did to fix the issue or b) a question about a different topic. If you keep arguing about this issue, you will be banned from the list. The list is for people to get help and to solve problems. People who ask for help and then tell us that we're wrong should not be asking questions here. Alan DeKok.
participants (4)
-
Alan DeKok -
Sergei Kodentsev -
Sergey Kodentsev
-
Winfield, Alister (Senior Solutions Architect)