Skip to content
A logging implementation for `log` which is configured via an environment variable.
Branch: master
Clone or download
KodrAus Merge pull request #129 from shepmaster/changelog-redirect
Redirect people to GitHub Releases for changes
Latest commit ecbcae2 Mar 14, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
examples Make all dependencies optional (#100) Nov 3, 2018
src prepare for 0.6.1 release (#128) Mar 7, 2019
tests Support capturing for cargo test (#127) Mar 3, 2019
.travis.yml Address review suggestions Nov 7, 2018
Cargo.toml prepare for 0.6.1 release (#128) Mar 7, 2019
LICENSE-MIT prepare for 0.6.1 release (#128) Mar 7, 2019

env_logger Build Status Maintenance Documentation

Implements a logger that can be configured via environment variables.


In libraries

env_logger makes sense when used in executables (binary projects). Libraries should use the log crate instead.

In executables

It must be added along with log to the project dependencies:

log = "0.4.0"
env_logger = "0.6.1"

env_logger must be initialized as early as possible in the project. After it's initialized, you can use the log macros to do actual logging.

extern crate log;
extern crate env_logger;

fn main() {

    info!("starting up");

    // ...

Then when running the executable, specify a value for the RUST_LOG environment variable that corresponds with the log messages you want to show.

$ RUST_LOG=info ./main
[2018-11-03T06:09:06Z INFO  default] starting up

In tests

Tests can use the env_logger crate to see log messages generated during that test:

log = "0.4.0"

env_logger = "0.6.1"
extern crate log;

fn add_one(num: i32) -> i32 {
    info!("add_one called with {}", num);
    num + 1

mod tests {
    use super::*;
    extern crate env_logger;

    fn init() {
        let _ = env_logger::builder().is_test(true).try_init();

    fn it_adds_one() {

        info!("can log from the test too");
        assert_eq!(3, add_one(2));

    fn it_handles_negative_numbers() {

        info!("logging from another test");
        assert_eq!(-7, add_one(-8));

Assuming the module under test is called my_lib, running the tests with the RUST_LOG filtering to info messages from this module looks like:

$ RUST_LOG=my_lib=info cargo test
     Running target/debug/my_lib-...

running 2 tests
[INFO my_lib::tests] logging from another test
[INFO my_lib] add_one called with -8
test tests::it_handles_negative_numbers ... ok
[INFO my_lib::tests] can log from the test too
[INFO my_lib] add_one called with 2
test tests::it_adds_one ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured

Note that env_logger::try_init() needs to be called in each test in which you want to enable logging. Additionally, the default behavior of tests to run in parallel means that logging output may be interleaved with test output. Either run tests in a single thread by specifying RUST_TEST_THREADS=1 or by running one test by specifying its name as an argument to the test binaries as directed by the cargo test help docs:

$ RUST_LOG=my_lib=info cargo test it_adds_one
     Running target/debug/my_lib-...

running 1 test
[INFO my_lib::tests] can log from the test too
[INFO my_lib] add_one called with 2
test tests::it_adds_one ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured

Configuring log target

By default, env_logger logs to stderr. If you want to log to stdout instead, you can use the Builder to change the log target:

use std::env;
use env_logger::{Builder, Target};

let mut builder = Builder::from_default_env();;


Stability of the default format

The default format won't optimise for long-term stability, and explicitly makes no guarantees about the stability of its output across major, minor or patch version bumps during 0.x.

If you want to capture or interpret the output of env_logger programmatically then you should use a custom format.

You can’t perform that action at this time.