Michael Chernyakhovsky wrote:
i use radrelay there are errors in log from rlm_detail like Error: rlm_detail: Couldn't open file /var/log/radius/radacct/detail-relay: Bad file descriptor
[...]
Bad file description error appear because radrelay can remove detail file while rad_detail trying to aquire filelock, I think (line 655 of radrelay.c).
I don't think so: you can continue to write in a file which has been unlinked.
so detail_move can be called by radrelay while rad_detail already opens detail (line 201) have outfd and try to aquire lock. after radrelay made rad_unlockfd(fileno(fp), 0) (line 670), rlm_detail try to fdopen (line 243) and will get error.
Indeed, things are done in the wrong order. This was already discussed on the freeradius-devel mailing list. The thread starts here: http://lists.freeradius.org/pipermail/freeradius-devel/2005-March/008139.htm... I think the fixes are in CVS head but they were never included in any stable release.
btw, why to sleep 1000ms on 665@radrelay.c? how rlm_detail can write something to detail.work, while file is locked by radreplay?
rlm_detail opens the file and wait for the lock. During this time, the file may be renamed by radrelay, but rlm_detail doesn't notice it. Therefore the file descriptor in rlm_detail points to detail.work. -- Nicolas Baradakis