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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exclude cfg.Stderr if only Stdout is provided in env var #136

Open
Bidon15 opened this issue Aug 22, 2022 · 1 comment 路 May be fixed by #135
Open

Exclude cfg.Stderr if only Stdout is provided in env var #136

Bidon15 opened this issue Aug 22, 2022 · 1 comment 路 May be fixed by #135
Labels
P3 Low: Not priority right now

Comments

@Bidon15
Copy link

Bidon15 commented Aug 22, 2022

Introduction 馃憢

If I want to change the logging output from Stderr to Stdout, the os env GOLOG_OUTPUT should be changed to stdout
Still, after setting env to only stdout - I still see that the same log is duplicated in both pipelines(StdErr, Stdout)
This behaviour was found during testing in testground and the testable application is using ipfs/go-log/v2 logger

  • ERROR logs show the same as OTHER

Example of testground's log

Aug 22 11:38:39.023690	INFO	65.2779s      ERROR << instance[002] (9c984e) >>
Aug 22 11:38:39.023713	INFO	65.2779s      ERROR << instance[002] (9c984e) >> /_____/  /_____/  /_____/  /_____/  /_____/
Aug 22 11:38:39.023753	INFO	65.2780s      ERROR << instance[002] (9c984e) >>
Aug 22 11:38:39.023794	INFO	65.2780s      ERROR << instance[002] (9c984e) >> Started celestia DA node
Aug 22 11:38:39.023826	INFO	65.2780s      ERROR << instance[002] (9c984e) >> node type: 	bridge
Aug 22 11:38:39.023868	INFO	65.2781s      ERROR << instance[002] (9c984e) >> network: 	private
Aug 22 11:38:39.023901	INFO	65.2781s      ERROR << instance[002] (9c984e) >>
Aug 22 11:38:39.023954	INFO	65.2782s      ERROR << instance[002] (9c984e) >> /_____/  /_____/  /_____/  /_____/  /_____/
Aug 22 11:38:39.023989	INFO	65.2782s      OTHER << instance[002] (9c984e) >> 2022-08-22T11:38:39.023Z	INFO	node	node/node.go:104	
Aug 22 11:38:39.024010	INFO	65.2782s      ERROR << instance[002] (9c984e) >>
Aug 22 11:38:39.024025	INFO	65.2782s      OTHER << instance[002] (9c984e) >>
Aug 22 11:38:39.024070	INFO	65.2783s      OTHER << instance[002] (9c984e) >> /_____/  /_____/  /_____/  /_____/  /_____/
Aug 22 11:38:39.024100	INFO	65.2783s      OTHER << instance[002] (9c984e) >>
Aug 22 11:38:39.024126	INFO	65.2783s      OTHER << instance[002] (9c984e) >> Started celestia DA node
Aug 22 11:38:39.024148	INFO	65.2784s      OTHER << instance[002] (9c984e) >> node type: 	bridge
Aug 22 11:38:39.024168	INFO	65.2784s      OTHER << instance[002] (9c984e) >> network: 	private
Aug 22 11:38:39.024206	INFO	65.2784s      OTHER << instance[002] (9c984e) >>
Aug 22 11:38:39.024227	INFO	65.2784s      OTHER << instance[002] (9c984e) >> /_____/  /_____/  /_____/  /_____/  /_____/
Aug 22 11:38:39.024249	INFO	65.2785s      OTHER << instance[002] (9c984e) >>

Solutions 馃

There are 2 approaches that I've found for myself:

  • If we set the env GOLOG_FILE to /dev/null and GOLOG_OUTPUT = stdout , then Stderr (hence, ERROR in testground) won't appear anymore
  • If the user is explicitly setting the env to only stdout, the why should we also leave Stderr flag to true? There is already a possibility to add multiple options in the env, so I propose the selection to be more strict. Example: feat: exclude stderr output if only stdout is passed in env聽#135
@Bidon15 Bidon15 added the need/triage Needs initial labeling and prioritization label Aug 22, 2022
@welcome
Copy link

welcome bot commented Aug 22, 2022

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

  • "Priority" labels will show how urgent this is for the team.
  • "Status" labels will show if this is ready to be worked on, blocked, or in progress.
  • "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 Low: Not priority right now
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants