possible radutmp problem in 2.1.4 and/or 2.1.5-git(2009-04-17 state)?

[Rozsahegyi Bela]

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