exfile / file locking
p.mayers at imperial.ac.uk
Tue Jul 25 13:34:33 CEST 2017
Context: we have quite an involved config that was built on 2.x, and we
used to make use of the sql_log module, with a locally-constructed
external process which follows the file and relays to our SQL service.
That external process has a very carefully constructed open/lock/rename
scheme designed to cooperate with how 2.x worked.
That module has gone away on 3.x and we've been using an instance of sql
with the null driver and "logfile" option set, which I was under the
impression used the same locking scheme.
We don't use the detail writer/reader construction because we're using
this in the "postauth" section, for logging of auths on devices which
don't do useful accounting (layer2 switches doing mac-based VLANs).
Having finally got round to serious porting to 3.x, we're seeing
corruption of this file on 3.0.15 and I am suspicious of the exfile
locking functions which I see are now being used for this. Specifically:
...seems to perform an fstat/re-open-if-unlinked check, but this happens
*after* any fcntl locking has been done, and there's no attempt to
re-lock the file on this re-open. So, if this codepath gets triggered,
the file is now held and written to without locking, when it should be
More generally, I've re-read the exfile code a couple of times and I am
suspicious of the basic construction. What performance problem is the
open/dup caching setup intended to solve? Put another way, why not
open/close the file using the traditional posix APIs on each run?
More information about the Freeradius-Devel