Today I got bit by

If you initialize both env_logger and eventlog in the same process it will crash, and you'll waste a bunch of time looking for the problem in the wrong place.

Ironically you'll think "If only the logging worked, then I could easily track this down", while the hint is, clearly, that you're not seeing any logs. :upside_down_face:

2 Likes

If you set RUST_BACKTRACE=1 the panic message will include a backtrace pointing to the exact line that triggered the panic.

In this case, env_logger::init() explicitly says it'll crash if you've initialized another global logger:

(you can use the env_logger::try_init() function for a non-crashing version)

1 Like

Unfortunately stdout/stderr do not exist in a Windows service context, so that would be of limited use -- unless there's a way to dump them directly to a file?

Hm. Now that you mention it, RUST_BACKTRACE should be made to be able to output using OutputDebugString().

Oh, I figured it was a bad idea, I just hadn't done it before so I didn't know it would crash. I have service:ified two other daemons the past weeks and carefully avoided initializing both loggers simultaneously. The issue was basically sloppy copy/paste:

fn main() {
  // .. logging was initialized here ..

  #[cfg(windows)]
  if args.run_as_service {
    // This function initializes eventlog..
    service::win::run(args)?;
    return Ok(());
  }

  // .. while it should have bee initialized here ..
}

.. and it didn't occur to me to look in main(), because obviously I wouldn't be initializing env_logger before kicking off the service. ... cough, cough. :neutral_face:

This experience has reminded me that I need to find out how complicated it is to do remote debugging of Rust applications in a Windows environment. Services are just so much easier to deal with using a remote debugger.