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: https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/main/exfile.... ...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 locked. Bug? 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? Regards, Phil