On 7 Apr 2014, at 12:33, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 7 Apr 2014, at 11:39, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 07/04/14 11:32, Phil Mayers wrote:
On 07/04/14 11:07, Arran Cudbard-Bell wrote:
20 internet points if you can spot the issue...
Wack wack oops.
Good old fnctl locking! Many thanks to AT&T for gifting us their behaviour...
Maybe it should be switched to flock() given FreeRadius is threaded? IIRC the only external programs (that come with the server) relying on the locking mode are radsqlrelay and radrelay?
Oh dear. Seems I might have instigated this:
http://lists.freeradius.org/mailman/private/freeradius-devel/2012-December/0...
...which triggered:
https://github.com/FreeRADIUS/freeradius-server/commit/582852042b4aa6810a683...
Oops... Sorry!
Ha, all your fault, all your fault :)
flock is sometimes just a wrapper around fcntl so may be just as broken, at least by moving to something we know is broken in terms of reflecting lock states internally, it means that we'll account for it in the code.
Anyway, I've just added a mutex around the writes for now.
I spent a few days investigating locking schemes on *NIX a while back and , came to the conclusion the only sane way of implementing a sane file locking scheme is to have a structure in the server core which holds all the currently open file handles, and their lock states.
The entries for the files would reflect the locking state presented to other processes with fcntl.
Entries would should probably persist after whatever needed the lock has released it, and expire out after a period of inactivity, else will have to initialise a mutex on every file access.
Just checked, and all the other modules which use rad_lockfd are marked as THREAD_UNSAFE. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2