tracing-subscriber 0.3.1 does not respect RUST_LOG

[theduke]

Bug Report

Version

tracing-subscriber 0.3.1

Platform

Linux

Description

tracing-subscriber seems to incorrectly handle the RUST_LOG env var.

After tracing_subscriber::fmt::init() I only get INFO and above events, regardless of the RUST_LOG env var (RUST_LOG=trace, RUST_LOG=crate=trace, ...)

Downgrading to 0.2 fixes this.

(I checked the release notes for changed behaviour, but it seems like there aren't any relevant alterations)

[davidbarsky]

I’ll update the changelog later, but the EnvFilter functionality is now behind an off-by-default feature flag called env-filter. You’ll need to add that to your Cargo.toml.

(The documentation for EnvFilter alludes to this, but this should be in a more prominent spot: https://docs.rs/tracing-subscriber/0.3.1/tracing_subscriber/struct.EnvFilter.html)

[hawkw]

I’ll update the changelog later, but the EnvFilter functionality is now behind an off-by-default feature flag called env-filter. You’ll need to add that to your Cargo.toml

The changelog does mention the feature flagging change: https://github.com/tokio-rs/tracing/blob/v0.1.x/tracing-subscriber/CHANGELOG.md#breaking-changes but it may not be obvious what behavior this changes, so we might want to clarify that changelog entry.

I think the most important docs improvement, though, might be to change the documentation for methods like fmt::init, that include an EnvFilter in the configured subscriber, to explicitly state that the feature flag is necessary for RUST_LOG filtering.

[hawkw]

I think the most important docs improvement, though, might be to change the documentation for methods like fmt::init, that include an EnvFilter in the configured subscriber, to explicitly state that the feature flag is necessary for RUST_LOG filtering.

Actually, now that I think about it, we could probably change init, at least, to include a Targets filter instead of EnvFilter when the feature flag is disabled. That way, we would still get RUST_LOG filtering, but would specifically not enable span field value filtering (which is why EnvFilter is feature flagged).

[rcoh]

perhaps we could log a warning if RUST_LOG is set but the feature isn't enabled in tracing_subscriber::fmt::init()? I suspect this will save a lot of people a lot of debugging time.

[dzamlo]

Despite enabling the env-filter, using tracing_subscriber::fmt::init() is not enough.

I have to manually add the filter:

tracing_subscriber::fmt()
        .with_env_filter(EnvFilter::from_default_env())
        .with_writer(non_blocking)
        .init();

Is it corect that this is not the expected behaviour?

[Firstyear]

I can reproduce this as well:

[package]
name = "tracing_demo"
version = "0.1.0"
edition = "2021"

[dependencies]
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter", "std", "fmt"] }

#[macro_use]
extern crate tracing;

fn main() {
    tracing_subscriber::fmt().init();

    debug!("This is a debug message");

    trace!("This is a trace message");
}

Using RUST_LOG=trace or debug both will not show the above messages.

tracing-subscriber v0.3.5
tracing v0.1.29
rustc 1.57.0 (f1edd0429 2021-11-29)

[kafji]

@Firstyear that's because tracing_subscriber::fmt().init() is not same as tracing_subscriber::fmt::init().

• tracing_subscriber::fmt::init() => initialize subscriber with opinionated configurations i.e. with with_env_filter(EnvFilter::from_default_env())
• tracing_subscriber::fmt().init() => create subscriber builder (with empty configurations) and then initialize it as global subscriber

It is confusing, #1329

tl;dr

• add with_env_filter(EnvFilter::from_default_env())
• or use fmt::init()

[Firstyear]

Yes, I think the docs also suggested at one point .init() as well, as I remember copy-pasting this line.

[davidbarsky]

Gonna close this since this was fixed in tracing-subscriber 0.3.5 with #1781.