From 74f1d8598a6f603fdfaf6c0487375c40166b76ec Mon Sep 17 00:00:00 2001 From: bitflash-maintainer Date: Wed, 2 Sep 2026 16:44:57 +0000 Subject: log: do not latch the roll off when logrotate won the race The latch added in 456b3b4 treats every rename() failure as permanent. One is not: if an external rotator moves debug.log between the size check and the rename, the rename fails ENOENT. Nothing is wrong -- the file has just been rotated by someone else, and the reopen above has already recreated it -- but latching there would switch the cap off for the rest of the run on a race the operator cannot see or fix. Treat ENOENT as "already rotated" and carry on. It cannot loop: the reopen leaves an empty file, so the next line's size check does not fire. --- src/util.h | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'src') diff --git a/src/util.h b/src/util.h index 362494c..f699e42 100644 --- a/src/util.h +++ b/src/util.h @@ -429,6 +429,15 @@ inline int OutputDebugStringF(const char* pszFormat, ...) "debug.log grew past %lld MB; previous contents moved to debug.log.old (-maxdebugfilesize)\n", (long long)(nMaxDebugFileSize / 1024 / 1024)); } + else if (nRenameErrno == ENOENT) + { + // The file went away between the size check and the + // rename, so an external rotator (logrotate) got there + // first. Nothing left to roll and nothing wrong: the + // fopen above has already recreated it. Latching on this + // would let a benign race with logrotate switch the cap + // off for the rest of the run. + } else { // The file is still over the cap, so this branch would be -- cgit v1.2.3