fix(kolog): stop watching kmsg log if boot time can't be read - #1933
fix(kolog): stop watching kmsg log if boot time can't be read#1933magic-peach wants to merge 1 commit into
Conversation
If getBootTime() fails, KmeshModuleLog kept going with a zero-value bootTime. startTimestamp then gets computed against year 1, which is astronomically bigger than any real kmsg timestamp - so the 'timestamp < appStartTimestamp' check in parseKmsgLine is true for every single line, forever. End result: one error log line on startup and then Kmesh's kernel module logs are just silently never printed again, no matter what happens on the node. Added a canWatchKmsg check so we bail out instead of running a feature that can never do anything. Signed-off-by: Akanksha Trehun <akankshatrehun@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Codecov Report❌ Patch coverage is
... and 2 files with indirect coverage changes Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
/kind bug
Noticed this while looking at the dns resolver locking. If /proc/stat can't be read, getBootTime() returns an error and KmeshModuleLog logs it but keeps going with a zero-value bootTime. startTimestamp then ends up computed against year 1, which is something like 60 quadrillion microseconds - way past anything a real kmsg timestamp could ever be. So the staleness check in parseKmsgLine is true for every line, forever, and the kernel module logs just go dark for the rest of the process's life with no further indication anything's wrong.
Added a small canWatchKmsg check so it bails instead of spinning up a goroutine that can structurally never print anything.