Why do info,debug macros not work

I'm using crate::stderrlog.
Message appear from main and one of its mod, others don't. I do not understand why this is happening. It's impossible to debug. It looks like the solution to this issue is simply received wisdom; which language feature is why I'm asking here.


There's not much information here to go on; it's much more likely that someone will be able to answer you successfully if you can point us to some actual code that exhibits the problem.

1 Like

Thanks for taking the time to reply!
Sorry for the brevity, I thought it would be something simply I'm just not seeing.

Just a line like
info!("hello world!");
printn!("Hello world");

each of which work in main() and a module brought in as

mod queue;
use queue::queue::*;

Another module,

mod ptisms_lazy_static;
use crate::ptisms_lazy_static::lazy_static::*;

At this point I'm trying anything to get output from the lazy_static module, so the verbose path.

logging works in #[cfg(test)] for another module that uses ptisms_lazy_static when the logger is initialized as follows:

    fn init_logger() {

which is how the logger is initialized in main(). I wasn't getting output from the lazy_static module until I realized it had to be initialized in the #[cfg(test)] module; which makes the lack of output when the module's called from main() even more perplexing.

Well, looks like I screwed the pooch on this one, eh?

Sorry I didn't live up to reporting expections!

I /so/ promise to do better next time. Really.

The use statements don't matter here, all they do is make it more convenient to use stuff in them. And the way in which you write the use never matters as long as it points to the same thing in the end (with crate or without, etc).

The difference must be in the functions called from main (just in case there's any confusion, you can't call modules), but you didn't post what main or the functions you call from it look like. As mentioned in the previous reply, it would make it a lot easier to help if you posted code that exhibits this problem.

For example, with

# Cargo.toml
name = "some_crate"
version = "0.1.0"
edition = "2021"

stderrlog = "0.5.4"
log = "0.4.20"
// src/main.rs
mod ptisms_lazy_static;
mod queue;

fn main() {

// src/ptisms_lazy_static.rs
pub fn hello() {
// src/queue.rs
pub fn world() {

the logging works just fine.

1 Like

I didn't post all the code b/c it's thousands of lines right now. This is not a new project. It's been running for over a year. I'm not about to try to create a reproducer b/c as you demonstrated, any reproducer is not going to demonstrate the problem.

Thank you for confirming that the use statements are not the issue, as that was related to putting mod NAME {} declarations inside those files. Of course that made no difference. I'm sure someday I'll figure it out. It's not a show-stopper, and it's obviously something simple that I'm overlooking. As I look at it, there are several modules that aren't logging to stderr. I think it also might be related to when a lazy_static gets called vs. when stderrlog gets going; which is weird as stderrlog happens just after declaring a ctrl/c handler (for systemctl). It could also be something as simple as scope, as stderrlog is declared in main(). Putting it into a lazy_static was a non-starter.
Yes, I'm aware lazy_static is deprecated.
[updated to add]
There's another module, related to moka-rs that also attempts to log. It uses lazy_static declarations and does its own logging. lazy_static is implicated somehow, but it's not the only reason; which could be a red herring.

It seems that you were using mod name {} inside name.rs (or name/mod.rs). That's not how it is intended to be used, since this leads to the hierarchy like crate::module::module::item, while the one you probably expect is crate::module::item. In general, there must be one and only one mod statement for each module - either wrapping it inline in braces, or referring to another file; but if you already have mod something; referring to something.rs, the contents of something.rs would be the contents of this module, without any additional wrapping.

I don't understand what you're trying to say with this statement— By definition, a reproducer will demonstrate the problem, or else it's not a reproducer.

Usually, these are made by starting with the whole project and ripping out parts that are likely irrelevant to the problem at hand. That process almost inevitably results in either code small enough to share or a lead in the form of something mattering that you thought shouldn't. Either way, it's usually a pretty efficient means to figure out what's going on.


I appreciate the fact that you're trying to help.

I'm just going to work around the problem until I figure it out. The original post was to see if this issue was solved via "received wisdom". The answer is "no". It's just too complex a problem to get to a reproducer. Too many modules with what's probably weird code. Too much state to reproduce. It works in #[cfg(test)] after initializing stderrlog. I can see the values in that mode. Someday I will see the nominal values in production. Such is the way of the world.

Agreed. I was trying to figure out why it works in queue.rs despite the fact that it contains a mod{} block. The redundancy was a last-ditch attempt to find a reason by reproducing the state of a working module inside another module. The mod{} declaration in queue.rs should've been removed after refactoring. Such is the way of the world.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.