3.0.2: rlm_sql_null duplicating its statements

[Arran Cudbard-Bell]

On 7 Apr 2014, at 12:33, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:

> 
> On 7 Apr 2014, at 11:39, Phil Mayers <p.mayers at 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/007356.html
>> 
>> ...which triggered:
>> 
>> https://github.com/FreeRADIUS/freeradius-server/commit/582852042b4aa6810a683383809de234c7bd98a3
>> 
>> 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 at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140407/5001b9da/attachment-0001.pgp>