Re: freeradius2.1.6| buffered-sql | acctstoptime problems
Thanks Ivan for quick responses. I calculated it correctly in dialup.conf file and restarted radius process and it looks like it's not catching up from the point before restart. Instead of that it's reading full detail.work file? why is like that? Any bug in my code? Thanks, Rams.
How to interpret AcctStopDelay filed?
It's the delay in seconds.
Is there any SQL query readily available to update acctstoptimes correctly in FR? please suggest.
You subtract the delay from the time. For MySQL: http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html#function... Ivan Kalik Kalik Informatika ISP
Hi,
Thanks Ivan for quick responses. I calculated it correctly in dialup.conf file and restarted radius process and it looks like it's not catching up from the point before restart. Instead of that it's reading full detail.work file? why is like that? Any bug in my code?
as it currently stands, if you quit then it'll start reading the detail.work from the very beginning - there is no tail/stripping or checkpointing of the file. it'd be good for such feature to be added at some point (i dont have time to dig/fix it) alan
Alan Buxey wrote:
as it currently stands, if you quit then it'll start reading the detail.work from the very beginning - there is no tail/stripping or checkpointing of the file. it'd be good for such feature to be added at some point (i dont have time to dig/fix it)
It would need to (somehow) mark each record in the detail file as "handled". Ideally, without breaking the existing format, OR using any extra bytes on the disk. Alan DeKok.
Hi,
It would need to (somehow) mark each record in the detail file as "handled". Ideally, without breaking the existing format, OR using any extra bytes on the disk.
can it not throw away the data from the detail.work as it completes it? alan
Alan Buxey wrote:
It would need to (somehow) mark each record in the detail file as "handled". Ideally, without breaking the existing format, OR using any extra bytes on the disk.
can it not throw away the data from the detail.work as it completes it?
Er... how? It's a text file on the disk. There's no way of saying "re-set the start of the file to be 10K ahead of where it is now". File *truncation* is supported in POSIX. But truncating from the start of the file isn't in POSIX. Hmmm... maybe over-writing it with spaces would work... or something else might go wrong. But really, if it's going to be tweaked, it should probably be redesigned from the ground up. Alan DeKok.
Hi,
File *truncation* is supported in POSIX. But truncating from the start of the file isn't in POSIX.
ah yes. been a while.
Hmmm... maybe over-writing it with spaces would work... or something else might go wrong.
or reverse it when making the .work copy and read from the end of the file.... alan
Alan Buxey wrote:
Hmmm... maybe over-writing it with spaces would work... or something else might go wrong.
or reverse it when making the .work copy and read from the end of the file....
That's hard... the detail.work file is created via a "rename", which is nearly zero cost. Alan DeKok.
Alan Buxey wrote:
Hmmm... maybe over-writing it with spaces would work... or something else might go wrong.
or reverse it when making the .work copy and read from the end of the file....
That's hard... the detail.work file is created via a "rename", which is nearly zero cost.
Alan DeKok.
Counter? Write detail.work.counter onto the disk, increment it every time packet is processed and return to zero when detail.work is deleted. It will say how many packets to skip when radiusd is restarted. Ivan Kalik Kalik Informatika ISP
Ivan Kalik wrote:
Counter? Write detail.work.counter onto the disk, increment it every time packet is processed and return to zero when detail.work is deleted. It will say how many packets to skip when radiusd is restarted.
Hmm... OK. Or slightly differently: the offset in the file of where it last read a packet. Maybe for 2.1.8. Alan DeKok.
Alan DeKok wrote:
Ivan Kalik wrote:
Counter? Write detail.work.counter onto the disk, increment it every time packet is processed and return to zero when detail.work is deleted. It will say how many packets to skip when radiusd is restarted.
Hmm... OK. Or slightly differently: the offset in the file of where it last read a packet.
Yep that's a good option.
Maybe for 2.1.8.
This is pretty much a none issue. Just have the detail file writer start a new file every minute/hour, then the number of repeated entries is very small. It's only when you have it start a new file every day, or use one monolithic detail file that you run into problems. -Arran
Arran Cudbard-Bell wrote:
This is pretty much a none issue. Just have the detail file writer start a new file every minute/hour, then the number of repeated entries is very small. It's only when you have it start a new file every day, or use one monolithic detail file that you run into problems.
Having hourly detail files is recommended, and does help. But for sites doing 100 acct/s, that means having ~300K packets in the file. Alan DeKok.
I calculated it correctly in dialup.conf file and restarted radius process and it looks like it's not catching up from the point before restart. Instead of that it's reading full detail.work file? why is like that? Any bug in my code?
No, that's what it's supposed to do - finish detail.work, delete it and then copy detail to detail.work etc. Ivan Kalik Kalik Informatika ISP
participants (5)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Ivan Kalik -
ramesh p