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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
