[1.0] fix logging race in nsexec (regression in rc94) #3130
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.
This is a backport of #3120 to release-1.0 branch,
fixing rare
but criticalissue #3119. Update: this is not critical -- the effect is we lost onedebug log entry, and get a weird error in runc logs.
As reported in issue #3119, there is a race in nsexec logging
that can lead to garbled json received by log forwarder, which
complains about it with a "failed to decode" error.
This happens because dprintf (used since the very beginning of nsexec
logging introduced in commit ba3cabf) relies on multiple write(2)
calls, and with additional logging added by 64bb59f (appeared in rc94)
a race is possible between runc init parent and its children.
The fix is to prepare a string and write it using a single call to
write(2).
Signed-off-by: Kir Kolyshkin [email protected]
(cherry picked from commit fb6ba04)
Signed-off-by: Kir Kolyshkin [email protected]