Phil Mayers wrote:
Hmm. Are you sure the "rad_lockfd" locking scheme is compatible with the one rlm_sql_log / radsqlrelay use(d)?
It can be. :)
Bear in mind that lockf is not guaranteed to be a mapping to fcntl (it is on Linux currently, IIRC). flock() is completely unrelated (and also doesn't work across NFS, in case this matters).
OK.
I know the Unix file locking APIs are vile, but having the locking method the server uses on files which external processes might access be a compile-time variable might make things difficult for people who have to read those files in external processes. They have to implement all three, and know which one the server binary is using right now...
It might be simpler to just make everything use fcntl locks. The rad_lockfd() code is a decade old. Many of the assumptions behind it may be no longer true. I'm OK with changing it to use fcntl locks. I'm OK with adding locking to rlm_sql_null. I'm OK with making rlm_sql_null do locking *all* the time, even when there's no sqlrelay program reading it. The extra locking costs very little. Alan DeKok.