rlm_detail and locking
p.mayers at imperial.ac.uk
Thu Feb 7 16:52:06 CET 2013
On 07/02/13 15:10, Brian Candler wrote:
> I have an application where I would like to read and process rlm_detail
> records in near-real-time (specifically to turn them into JSON and stuff
> them into a local database).
> I'm familiar with rlm_sql_log + radsqlrelay, and I know this is robust.
> So I was hoping to modify radsqlrelay to work with files being appended to
> by rlm_detail, but I turned up a wrinkle when checking the file locking in
> 2.2.x code.
> rlm_sql_log uses fcntl() locking only; but rlm_detail is different. It calls
> rad_lockfd_nonblock(), which uses lockf if available, else flock, and only
> uses fcntl if the other two are not available.
Yes. This was changed in "master".
> It looks like fcntl and flock locks are independent of each other:
Yes. But also be aware that lockf and fcntl are not guaranteed to be
equivalent either - POSIX in general specifies no relationship. They
happen to be the same under Linux, right now.
> Question: what's the safe way to process detail files? Is there a Perl
> implementation of radrelay I can hack from? Looks like the original C
> implementation of radrelay was removed in 2005 (acd40e2e)
Personally, I would just backport the "fcntl-only" commit - that way you
know you're getting fcntl locking:
More information about the Freeradius-Users