Tuc at T-B-O-H.NET wrote:
Ok, thanks. I have to do more work to see if radutmp EVER had a record for the user or not. My initial thought was that when the user logged off and an accounting stop record was sent, that it updated the radutmp file, and then "SOMETHING" happened that the sql radacct didn't get updated. I never thought that for some reason the accounting start and interim update records were getting into sql but none of it ever making radutmp.
radutmp is a historical hack. If you're using SQL, there's no need to use radutmp.
Are radutmp entrys ONLY created during accounting start requests, and deleted during accounting stop records (Or Accounting On/Off for a NAS), or can an accounting interim-update cause the creation of a radutmp entry that wasn't there previously?
I haven't looked at that module in a long time, sorry.
I *really* suggest not using radumtp if you're using SQL.
Is there an SQL version of "radwho"? I've taught the people to use radwho to determine who is logged on, and don't see another utility or string I can pass to radwho. From the README in doc directory : 4. LOG FILES 4a. /var/log/radutmp In this file the currently logged in users are held. The program "radwho" reads this file and gives you a summary. Rogue sessions can be deleted from this file with the "radzap" program. It also seems "radzap" depends on the accuracy of radwho to be able to pipe information ro radzap. So it seems to be able to use atleast 2 of the supplied utilities, radutmp is necessary and can't be substituted with SQL, unless I am looking in the wrong place. Thanks, Tuc