Hi,
We seem to be having the The maximum number of threads (32) are active
with Freeradius 1.0.3. Version 1.0.1 works just fine.
I tried to do a valgrind with - but when radiusd displays that message,
you can no longer kill it.
I have the debug output from the - and it shows the
On 4/17/07, Alan DeKok [EMAIL PROTECTED] wrote:
Rick Macdougall wrote:
Hi,
We seem to be having the The maximum number of threads (32) are active
with Freeradius 1.0.3. Version 1.0.1 works just fine.
Upgrade to 1.1.6. It has a whole host of fixes.
Yah, I've already downloaded
On 4/17/07, Alan DeKok [EMAIL PROTECTED] wrote:
Rick Macdougall wrote:
Hi,
We seem to be having the The maximum number of threads (32) are active
with Freeradius 1.0.3. Version 1.0.1 works just fine.
Upgrade to 1.1.6. It has a whole host of fixes.
Hi,
Upgraded to 1.1.6
Follow up.
It is updating/inserting records into the mysql radacct database but it
seems that an ACK is not sent back to the remote server and the thread is
not released. A minute later the remote server tries again, etc etc until
the threds max out at 32.
Regards,
Rick
-
List
Yep. Your backend is too slow to keep up. Accounting is inserts and
updates... Auth is selects.. BIG difference in speed...
Not a speed issue, the mysql records are inserted within milliseconds of the
detail file being written. Running radiusd -x shows the sql accounting
happening almost
On 4/19/07, Alan DeKok [EMAIL PROTECTED] wrote:
Rick Macdougall wrote:
Recompiled with --without-threads and it locks up hard on the first
accounting request. And when I say locks up hard, I mean not even a kill
-9 will stop it, I have to reboot the server.
Are you sure your OS isn't
Ok,
I've taken out the SQL accounting completely, left in the SQL authentication
and the problem still persists. On accounting packets with threads
disabled, the accounting process stops completely after one packet, on
accounting packets with threads enabled, the accounts process reports the
Well, I went through everything in the accounting { } and the problems turns
out to be radutmp
Any reason this might be a problem. The file gets created but never written
to. If I comment it out of the accounting { }, then everything, including
mysql records being written, works just fine.
,
Rick
PS - If you don't remember who I am check out the old cistron list mailings.
On 4/19/07, Alan DeKok [EMAIL PROTECTED] wrote:
Rick Macdougall wrote:
Well, I went through everything in the accounting { } and the problems
turns out to be radutmp
Any reason this might be a problem
Hi All,
No idea if anyone remembers me from the old Cistron list, but we are
finally upgrading to Freeradius.
In our configuration and testing we came across one small bug in the
accounting module.
accounting {
detail# always log to detail, stopping if it fails
Hi,
How does one go about using the preproxy_users file ?
We need it in this case because
1 - I have a attr_rewrite setup to add the domain to a user if there
is no domain part specified based on the DNIS (which works just fine)
2 - We have one domain we are proxying for with the default STRIP
Hi,
I believe the redback_telnet in checkrad.pl has a small bug.
Original code starting at line 1338
#Ask the question
@lines = $t-cmd(String = show subscribers active
$us...@$context);
if ($lines[0] =~ /subscriber $us...@$context/ ) {
Should be
#Ask the question
@lines =
12 matches
Mail list logo
