emabee / flexi_logger

A flexible logger for rust programs that can write to stderr, stdout, and/or to log files
Apache License 2.0
307 stars 50 forks source link

stdout_writer.rs panics on application boot #87

Closed tdudz closed 3 years ago

tdudz commented 3 years ago

hey @emabee

took the new 0.18.1 async stdout for a test and unfortunately its not working for me in two of my applications.

the first one panics on startup with the following message: thread panicked while processing panic. aborting. it doesnt give any additional info

the other application panics and says: thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', /Users/tdudz/.cargo/registry/src/github.com-1ecc6299db9ec823/flexi_logger-0.18.1/src/primary_writer/stdout_writer.rs:144:37

emabee commented 3 years ago

Could you provide the logger initialization(s) you‘re using? Which platform are you using? Linux?

tdudz commented 3 years ago

the issue occurs on both linux and macOS, i tried both

    Logger::try_with_str("info")
        .unwrap()
        .log_to_stdout()
        .write_mode(WriteMode::Async)
        .format(log_format)
        .start()
        .unwrap();

its strange because i init it the same way in a different app and it ran fine there

the function log_format is just

// custom log formatting for flexi_logger handler
pub fn log_format(
    w: &mut dyn std::io::Write,
    now: &mut flexi_logger::DeferredNow,
    record: &log::Record,
) -> Result<(), std::io::Error> {
    write!(
        w,
        "{} [{}] {}",
        now.now().format("%Y-%m-%d %H:%M:%S%.6f"),
        record.level(),
        &record.args()
    )
}
tdudz commented 3 years ago

oh wow, i happened to fix it. if i assign the logger handler to a variable, it no longer panics

let _logger = Logger::try_with_str("info")
        .unwrap()
        .log_to_stdout()
        .write_mode(WriteMode::Async)
        .format(log_format)
        .start()
        .unwrap();

any reason why?

emabee commented 3 years ago

That is indeed the correct solution. I will improve the error handling for this case, to make it more obvious why this has happened.

The need to keep the handle alive is documented (e.g. Logger::start or WriteMode), but I understand that this is still easily overlooked. I'm sure I'd also find it too late.