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.

1 files changed, 9 insertions, 0 deletions

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