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

[Alan DeKok]

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.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog