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.html I think the fixes are in CVS head but they were never included in any stable release. > btw, why to sleep 1000ms on [EMAIL PROTECTED] > 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
