Skip to content
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

Capture stdout and stderr to log4j log #50259

Merged
merged 6 commits into from
Jan 25, 2020
Merged

Conversation

rjernst
Copy link
Member

@rjernst rjernst commented Dec 17, 2019

This commit overrides the stdout and stderr print streams to be
redirected to the main elasticsearch.log file. While the Elasticsearch
project ensures stdout and stderr are not written to, the jdk or 3rd
party libs may do this, which can be unexepected for users used to
looking the elasticsearch log.

closes #50156

This commit overrides the stdout and stderr print streams to be
redirected to the main elasticsearch.log file. While the Elasticsearch
project ensures stdout and stderr are not written to, the jdk or 3rd
party libs may do this, which can be unexepected for users used to
looking the elasticsearch log.

closes elastic#50156
@rjernst rjernst added >enhancement :Core/Infra/Logging Log management and logging utilities v8.0.0 v7.6.0 labels Dec 17, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (:Core/Infra/Logging)

@rjernst rjernst requested a review from jasontedor December 17, 2019 01:52
Copy link
Contributor

@pgomulka pgomulka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM I left one question

throw new IOException("buffer closed");
}
if (b == 0) return;
if (b == '\n') {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so this looks fine in plaintext logs, but might end up harder to analyze with JSON logs. Why not adding \n to the buffer too?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would cause double the lines in the log. Think of it as making this equivalent to most of our logging calls do not contain a newline in the message. Log4j inserts newlines per message emitted.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense, thank you

Copy link
Member

@jasontedor jasontedor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good as discussed, I left a question.

@rjernst
Copy link
Member Author

rjernst commented Dec 17, 2019

@elasticmachine run elasticsearch-ci/bwc

Copy link
Member

@jasontedor jasontedor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good.

@polyfractal polyfractal added v7.7.0 and removed v7.6.0 labels Jan 15, 2020
@rjernst rjernst merged commit 0ec74f8 into elastic:master Jan 25, 2020
@rjernst rjernst deleted the logging1 branch January 25, 2020 18:59
rjernst added a commit that referenced this pull request Jan 25, 2020
This commit overrides the stdout and stderr print streams to be
redirected to the main elasticsearch.log file. While the Elasticsearch
project ensures stdout and stderr are not written to, the jdk or 3rd
party libs may do this, which can be unexepected for users used to
looking the elasticsearch log.

closes #50156
danielmitterdorfer added a commit to danielmitterdorfer/rally that referenced this pull request Jan 27, 2020
With this commit we avoid reading from stdout/stderr which might have
been closed by the application and rely solely on the process' return
code.

Relates elastic/elasticsearch#50259
danielmitterdorfer added a commit to elastic/rally that referenced this pull request Jan 27, 2020
With this commit we avoid reading from stdout/stderr which might have
been closed by the application and rely solely on the process' return
code.

Relates elastic/elasticsearch#50259
rjernst added a commit to rjernst/elasticsearch that referenced this pull request Jan 28, 2020
In elastic#50259 we redirected stdout and stderr to log4j, to capture jdk
and external library messages. However, a typo in the method name used
to redirect the stream in java means stdout is currently being
duplicated twice, and stderr not captured. This commit corrects that
mistake. Unfortunately this is at a level that cannot really be tested,
thus we are still missing tests for this behavior.
rjernst added a commit that referenced this pull request Jan 30, 2020
In #50259 we redirected stdout and stderr to log4j, to capture jdk
and external library messages. However, a typo in the method name used
to redirect the stream in java means stdout is currently being
duplicated twice, and stderr not captured. This commit corrects that
mistake. Unfortunately this is at a level that cannot really be tested,
thus we are still missing tests for this behavior.
rjernst added a commit that referenced this pull request Jan 30, 2020
In #50259 we redirected stdout and stderr to log4j, to capture jdk
and external library messages. However, a typo in the method name used
to redirect the stream in java means stdout is currently being
duplicated twice, and stderr not captured. This commit corrects that
mistake. Unfortunately this is at a level that cannot really be tested,
thus we are still missing tests for this behavior.
@jakelandis jakelandis removed the v8.0.0 label Jul 26, 2021
jiangyunpeng added a commit to jiangyunpeng/elasticsearch that referenced this pull request Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

JVM debug logs are not redirerected to the elasticsearch log
6 participants