Logging to stdout (instead of stderr) is a wrong default

[dpc]

Bug Report

I just lost decent amount of time debugging a problem that turned out to be tracing-subscriber logging to stdout which was overlooked during refactoring. This is a second, if not third time in the recent past where I've dealt with wrong defaults in tracing-subscriber creating issues.

I don't recall ever wanting to get my log output to stdout, and as far as I can tell logging to stderr is a well estabilished convention, to separate main program output from diagnostics.

At very least env_logger defaults to stderr , so does e.g. slog-term, so do most logging libraries I've used and can remember.

Is there any reason why tokio-subscriber would go against this convention?

I realize that at this point reverting the default might be a hassle, but just want to point it out and ask.

[mkpankov]

Also surprised with this.
This might be a performance consideration since logging a lot of data to unbuffered sink might be less performant. But I'd like the team to clarify this.

[dpc]

stdout will flush on newlines (uses std::io::LineWriter under the hood). Should be natural for any logging library to just write-out stuff in lines (or use LineWriter to gather output into newlines internally). In addition stdout is locked, which is making it possibly slower. So I doubt it is any perf optimization.

[hawkw]

I agree that it would probably be more correct to make stderr the default. We should probably change it.

IMO, changing the default output stream is semver-breaking, so we would need to do this in a tracing-subscriber 0.4. If we do an 0.4 release soon, we probably want to reassess some other default behaviors as well.

[Natr1x]

I agree that it would probably be more correct to make stderr the default. We should probably change it.

IMO, changing the default output stream is semver-breaking, so we would need to do this in a tracing-subscriber 0.4. If we do an 0.4 release soon, we probably want to reassess some other default behaviors as well.

Is it possible to put a warning/clarification in the documentation and README examples in the meantime. I also just lost a couple of hours due to this.

Edit:

I created a PR adding this kind of warning to the documentation since I recently ran into another bug caused by this.

[Victor-N-Suadicani]

Also just ran into this. The 0.3 version is from 2021 - perhaps the time is ripe soon for a breaking 0.4 release that could fix this? :)

[zesterer]

I have also just walked into this particular wall. I'm quite surprised that not only is stdout the default (which is bad because it has practical consequences for a lot of applications, not just because it's unconventional), but also that there appears to be no way to configure tracing_subscriber to use stderr at all. Why is this, and why not allow output to an arbitrary impl Writeer?

[Victor-N-Suadicani]

There is a way to configure it to use stderr, just see the example for the with_writer method.

[zesterer]

Thanks! I'd missed that.