This repository has been archived by the owner on Oct 13, 2023. It is now read-only.
[19.03 backport] logger: fix follow logs for max-file=1 ENGCORE-1165 #378
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of moby#39969 to 19.03; clean cherry-pick, no issues. Original description follows.
In case jsonlogfile is used with
max-file=1
andmax-size
set,the log rotation is not performed; instead, the log file is closed
and re-opened with
O_TRUNC
.This situation is not handled by the log reader in follow mode,
leading to an issue of log reader being stuck forever.
This situation (file close/reopen) could be handled in
waitRead()
,but fsnotify library chose to not listen to or deliver this event
(
IN_CLOSE_WRITE
in inotify lingo) as it's not portable,see fsnotify/fsnotify#252.
So, we have to handle this by checking the file size upon receiving
io.EOF
from the log reader, and comparing the size with the one receivedearlier. In case the new size is less than the old one, the file was
truncated and we need to seek to its beginning.
Fixes moby#39235. See the steps to verify in that issue.
Description for the changelog
jsonfile logger: Fix lollow logs stuck when max-size is set and max-file=1
ENGCORE-1165