On Fri, 2009-08-21 at 08:47 +0200, Alan DeKok wrote:
Yes... that's *supposed* to happen, but there may be reasons for it not actually happening.
e.g. race conditions, where the same user logs in twice, 1/10s apart. or maybe it's not the "same" username...
The race condition - ok. However, I'm 100% sure the username is the same. Otherwise, our sql query for duplicate rows wouldn't return anything, unless they're differing in some other manner. But, then I don't what that difference could be.
Go over the records again. Are they for the *same* user?
Yes, I'm sure. Lately, the duplicate entries have died down to near 0. We're now running cleanup jobs to remove any duplicate rows, and to "close" records for users that no longer have sessions on the NAS or that haven't been updated within 20 minutes. This appears to have fixed a lot of the problems we were having (admittedly, we should have implemented these cleanup procedures in the first place). I should mention the duplicate/triplicate/or more rows problem only happens when we've had to do mass kills on the NAS end, which then results in thousands of auth requests eventually hitting freeradius. This is likely where the race conditions are coming into play. mysql doesn't write the first record fast enough before the second, third, etc. are received and begin writing, too. I need to get the decoupled accounting, or at the very least, buffered sql working. BTW, what's the difference the two? Is one better than the other? Regards, Ranbir -- Kanwar Ranbir Sandhu Linux 2.6.27.29-170.2.78.fc10.x86_64 x86_64 GNU/Linux 11:44:44 up 10 days, 12:41, 5 users, load average: 1.41, 0.83, 0.43