Issue 4635: Address pipe reuse after configuration reload issues #6076
Conversation
This file contains hidden or 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
bryancall
approved these changes
Oct 28, 2019
Contributor
|
Thanks @bneradt, I've tried your patch on a test host and it seems to work as advertised! I am going to deploy it to some production machines too next week and report back here. |
Contributor
|
Cherry-picked to v9.0.x branch. |
Contributor
Works like a charm! Thanks. |
Contributor
Author
|
Glad to hear it. Thanks for the update and your detailed initial notes. Your repro steps made working with this issue much easier. |
Contributor
|
@zwoop can this be cherry-picked to 8.0.x too? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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 addresses the issue described by @ema :
#4635
I reproduced the inability to read from the pipe after trafficserver responded to the HUP signal and unlinked the pipe. I next removed the unlink and reproduced the leaked file descriptor Emanuele describes. I then added the close call in the LogFile destructor and the pipe is no longer leaked.
Notice further that I changed the wording in the code comments concerning the meta file for a pipe. Meta files are used only for log rotation and pipes are never rotated since that concept doesn't apply to a pipe. Thus we never associate a meta file with log pipes. This can be seen in the LogFile constructor:
https://github.com/apache/trafficserver/blob/92d4ef1/proxy/logging/LogFile.cc#L74
Notice that BaseLogFile is only created if the LogFile is not a pipe. BaseLogFile is the object that manages the meta file, thus meta files are (correctly) not created for pipes.