-
Notifications
You must be signed in to change notification settings - Fork 844
Address pipe remove on reload and add pipe reuse #6017
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
let me know what i can do to address build issues if anything |
| // reuse existing pipe if available | ||
| struct stat stat_p; | ||
| stat(m_name, &stat_p); | ||
| if (S_ISREG(stat_p.st_mode) && S_ISFIFO(stat_p.st_mode)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How can a file be a regular file and a fifo?
|
This needs to go to 9.0.0 presumably ? |
|
Eric's moved on, we'll probably need to close this out since it's not going to get fixed. @bneradt is working on this now. |
|
hey sorry for the delay but i can get brian’s comment addressed so y’all
can get this in
…On Tue, Oct 22, 2019 at 9:06 AM Alan M. Carroll ***@***.***> wrote:
Eric's moved on, we'll probably need to close this out since it's not
going to get fixed. @bneradt <https://github.com/bneradt> is working on
this now.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#6017?email_source=notifications&email_token=AAMM5W52BWY4VEFOBX3WE6LQP4QH5A5CNFSM4I74RHVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB6JMMQ#issuecomment-545035826>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMM5WZHL2GYPK2I5XBGBCTQP4QH5ANCNFSM4I74RHVA>
.
|
|
I've reproduced what @ema described with his excellent description in issue 4635. I applied @ericcarlschwartz 's change from this PR (using '||' instead of '&&' per Bryan's comment), and indeed it addresses the majority of Emanuele's issues. However, I notice that traffic_server still seems to be leaking the file descriptors with each -HUP against traffic_manager: I'll look into what can be tweaked to address the leak. |
|
Digging through LogObject.cc, this patch (added on top of Eric's) cleans up the leaked file descriptors: |
| roll_file = false; | ||
| } else { | ||
| if (S_ISFIFO(s.st_mode)) { | ||
| unlink(filename); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing this out locally, removing the unlink seems to get the behavior that addresses the concerns @ema raised.
However, do we have to worry about the comment at line 974:
https://github.com/apache/trafficserver/pull/6017/files#diff-75bc20fd8082b64381dec2cf402275feR974
It seems to indicate that the unlink is intentional so that the metadata is correct. Maybe the comment is incorrect though?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does the meta data files say about the fifo in your testing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading through the code, I see that the meta file is only used for log rolling which is not applicable to pipes. We don't even instantiate a BaseLogFile (which creates and maintains the meta file) for pipes:
LogFile::LogFile(const char *name, const char *header, LogFileFormat format, uint64_t signature, size_t ascii_buffer_size,
size_t max_line_size)
: m_file_format(format),
m_name(ats_strdup(name)),
m_header(ats_strdup(header)),
m_signature(signature),
m_max_line_size(max_line_size)
{
if (m_file_format != LOG_FILE_PIPE) { <<<<<<<< Note created for pipes.
m_log = new BaseLogFile(name, m_signature);
m_log->set_hostname(Machine::instance()->hostname);
} else {
m_log = nullptr;
}
In any case, the comment about unlinking the pipe to maintain the metadata for it seems to be a mistaken comment (assuming by metadata the author meant the meta file).
@ericcarlschwartz : I'll create a new PR with the close() call and manage the PR from there.
Thanks!
Brian
|
Issue was addressed in PR #6076. Closing this PR. |
|
Remember to remove Project / Milestone etc. on closed PRs. |
this addresses issue #4635
if you'd like to test and let me know if you like this @ema feel free
also reuses existing pipes so we don't just create a new one for every reload as discussed with @ema and @SolidWallOfCode at the summit