SQL Accounting problem with 1.0.3 - The maximum number of threads (32) are active

[Rick Macdougall]

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

PS - If you don't remember who I am check out the old cistron list mailings.


On 4/19/07, Alan DeKok <aland at deployingradius.com> 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.  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.
>
>   Weird.  I haven't run into any problems with radutmp on my system.
>
>   radutmp tries to lock the utmp file, so if one thread gets blocked, it
> may stop other threads, too.  I would double-check the file permissions,
> etc. on the radutmp file, and on the directory it's in.
>
>   Or, you may be mounting the radutmp file over NFS.  That would explain
> the process being un-killable when something goes wrong.  Most NFS
> implementations do things like mark the process as being in the kernel
> when certain NFS operations happen.  When NFS blocks, the process can't
> be killed, because you can't kill the running kernel, right?
>
>   This is arguably a kernel bug, just like core dumps can't be stopped
> vi CTRL-C.  I've run into both situations in the past.  And yes, I've
> had to reboot my system because some process was using a file over NFS,
> and something went wrong.
>
>   The solution is to *not* mount the log directory over NFS.  In fact,
> *all* of the file needed by FreeRADIUS should be on local disk.  If
> they're not, the process may block completely when NFS goes away.
> During this time, the process will likely be unkillable.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20070419/6bb5589e/attachment.html>