rlm_detail and locking

[Phil Mayers]

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:

https://github.com/FreeRADIUS/freeradius-server/commit/582852042b4aa6810a683383809de234c7bd98a3