rlm_detail and locking

Phil Mayers 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:
> http://www.mjmwired.net/kernel/Documentation/filesystems/locks.txt

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 mailing list