1.1.7 rlm_detail locking is broken

Brian De Wolf bldewolf at csupomona.edu
Mon Nov 26 21:14:53 CET 2007


I recently installed freeradius and have it forwarding accounting information.
I noticed that there were a lot of failed locks in the logs, so I began to
investigate.  In rlm_detail, I found this loop for locking:
        do {
                if (inst->locking) {
                        lseek(outfd, 0L, SEEK_SET);
                        if (rad_lockfd_nonblock(outfd, 0) < 0) {
                                tv.tv_sec = 0;
                                tv.tv_usec = 25000;
                                select(0, NULL, NULL, NULL, &tv);
                        } else {
                                DEBUG("rlm_detail: Acquired filelock, tried %d
                                      lock_count + 1);
                                locked = 1;
        } while (!locked && inst->locking && lock_count < 80);

This loop, if it fails on the first lock, might as well not try again.  Why?
Because it closes the file descriptor when it fails.  All of the following calls
just come back with 'bad file descriptor'.

The oddest part about this is that I had found this thread:

It looks like the locking should work perfectly!  But it seems these changes
never found their way into the 1.x series, despite having occurred two years
ago.  I poked around in CVS and found revision 1.43 which is when the corrected
locking was added.  I took a diff of revision 1.42 and 1.43, and applied it by
hand to 1.1.7.  I haven't had any complaints from freeradius about locking
issues since.

I have attached the patch.  Is there any reason this never found its way into
the 1.x series?  I see it's in the CVS head.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.1.7-rlm_detail-locking.patch
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20071126/6611ef57/attachment.ksh>

More information about the Freeradius-Devel mailing list