fix: Ensure main log file is tailed from the start#4146
Conversation
Thanks for pointing this out. My main concern was that log lines were not being output (an error) as they were racey from daemons starting prior to the tail.
Yeah, the missing log lines were about 0.5-1 second offset from the displayed Amavis ones. Some would show when Amavis was disabled but not the OpenDKIM/OpenDMARC IIRC (these were the earliest log lines). Your suggestion sounds fine 👍 I'll verify and update the PR tomorrow with that. |
georglauterbach
left a comment
There was a problem hiding this comment.
With @casperklein's explanation, I now understand the issue, and I agree with him. I'll block on this via review so that it does not get merged by accident.
|
I'll open a separate issue for the bug below. Resolved - Cause is not from this PRAfter verifying @casperklein advice as working well, I noticed that if I force stop the container (
Without them I only get that line logged once (internally since prior to this PR it's too early to output). It's a bit racey, and I know why it's a problem, but I just don't understand why the change here was introducing the crash loop 🤔 After the standard Amavis log lines, it's just this over and over: That'd be fixed if we ensure PID is cleaned up for container restarts too: docker-mailserver/target/scripts/startup/setup-stack.sh Lines 85 to 104 in 4f1d075 It's not really a blocker for this PR, some change here just better surfaced the regression introduced with v14 for the container restart skip feature. I'd still like to know what this PR does to cause the loop though 🤔 EDIT: My UPDATE: Not this PR 😅 I could reproduce without the volume mount with both the old For reference these are the SHA256 image digests: |
0 or 1 is equivalent for a fresh file, but when log lines already exist, you want to start from the line after the last one, not at it. Thus always increment the count by 1.
Co-authored-by: Casper <casperklein@users.noreply.github.com>
e350170

Description
I noticed a difference in log output when troubleshooting a recent issue. Depending on if
ENABLE_AMAVISwas on/off, earlier logs in this file did not appear. Thetouchdoesn't seem relevant as logs from starting up daemons were already present, but in this case only slightly delayed amavis logs were displayed.Syntax of the
tailcommand was slightly off, seems to require a+in front of the number given to-n👍Type of change
Checklist
CHANGELOG.md