You are right on with the NFS locking issue.
I believe that is exactly the problem, my only concern now is why it happens
with CentOS 4.x and not with Fedora Core 3.
More info in the morning as I'm currently having a beer (or 4) and watching
the Hockey playoffs.
Thanks for the help.
Regards,
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. The file gets created but never
> written to. If I comment it out of the accounting { }, then everything,
> including mysql records be
On Thu 19 Apr 2007, 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. The file gets created but never
> written to. If I comment it out of the accounting { }, then everything,
> includi
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.
Reg
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
ma
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
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 buggy? It's a bad problem if "kill -9"
doesn't work.
Rick Macdougall wrote:
> 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.
That says that the
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.
Output from radiusd -
Wed Apr 18 15:43:13 2007 : Debug: radius_xlat: 'INSERT into radacct
(RadAcctId,
A
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 i
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 info/subscribe/
On Wed 18 Apr 2007, Rick Macdougall wrote:
> 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
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 and
On Tue 17 Apr 2007, Rick Macdougall wrote:
> 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
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
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 acco
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.
Alan DeKok.
--
http://deployingradius.com - The web site of the book
h
17 matches
Mail list logo
