Thanks for a very quick answer!
...and this point freeze the process, rarely only the kill -9 the solution for stop.
That looks like another process is locking the file.
I do not think so, because this is a dedicated server for radius, but on the next stop, i try lookup with lsof or other strace trick.
When delete the radutmp, and start the radius, the authentication is very fast, a custom, radclient style monitoring system say about 10-12 msec for a login. If the radutmp file grow, this time going over 30 msec, when the radutmp file in the /dev/shm "ramdisk". If the radutmp file on standard filesystem, had similar effect, but a little slower respond.
OK... so what kind of file system are you using when it stops working? NFS?
Nowise :) The /dev/shm is tmpfs, the normal filesystem is XFS and noatime,nodiratime mount option for the radius directory: /dev/md3 on /usr/local/freeradius type xfs (rw,noatime,nodiratime) I have an other idea that this may be a kernel related bug, the current kernel version is 2.6.27.13 with grsec patch, but late night I change the kernel, to exclude this chance.
Could someone help, what should I do? Ran out of ideas...
Don't put any of the server files on NFS.
The radutmp file usage better me, than the sql backend, because the radrelay do a little delay.
If you're using radrelay, the delay doesn't matter. Use SQL for user logins, not radutmp.
What would you propose? SQL select from the big accounting table for already logged in users (~1.2 million row), or a smaller table dedicatad this functions with insert on log in and delete on log off? RB