Modifying the compressFile function to correct intermittent log file rotation crashes #80
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…er it has been compressed. I believe there is a race condition between the compression and the unlink and when the unlink whens it throws an ENOENT error.
|
@wufe-natuku Thank you for your contribution. Would you please update to make sure the unit tests pass? I suspect it's likely a timing issue that's causing it. Thanks! |
|
Some long-overdue refactoring of the transport has occurred. Closing this PR in favor of #107. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I have been encountering log rotation crashes mentioned in issue #9 almost constantly on my production server. While working through the issue, I have come to believe the cause is a race condition in the compressFile function. The file to be archived is opened for read and them piped into the compressor. This pipe is an asynchronous action. Right after that, the file is unlinked. I believe there is a race condition between the unlinking and the openning for compression. If the file is not opened before the unlink occurs, the unlink will delete the file. This in turn causes the failure to open because the file is gone.
After doing some reading about the pipe and unlink functions, I am proposing this fix.
If you wait to unlink until the pipe finishes, the race condition is gone. This fix has cleared up the issue on my production server.