Non-blocking writer not writing to file.

[veeshi]

I am trying to log to a file using the non blocking writer but no log file is being created and nothing is being written to it.

Below is the setup for tracing.

pub fn tracing_setup(level: &LogLevel) -> WorkerGuard {
    let file_appender = tracing_appender::rolling::minutely("/tmp/app/", "app.log");
    let (non_blocking, guard) = tracing_appender::non_blocking(file_appender);

    let subscriber = tracing_subscriber::FmtSubscriber::builder()
        .with_writer(non_blocking)
        .json()
        .with_max_level(tracing::Level::TRACE)
        .finish();
    tracing::subscriber::set_global_default(subscriber).unwrap();

    guard
}

The guard is not dropped in the code which calls the setup and lives for as long the program.

I have even tried a blocking writer using just the rolling file appender but that does not write any logs as well.

pub fn tracing_setup() {
    let file_appender = tracing_appender::rolling::minutely("/tmp/app/", "app.log");

    let subscriber = tracing_subscriber::FmtSubscriber::builder()
        .with_writer(file_appender)
        .json()
        .with_max_level(tracing::Level::TRACE)
        .finish();
    tracing::subscriber::set_global_default(subscriber).unwrap();
}

[davidbarsky]

Two questions:

• Can you show your main function with the worker guard?
• Do you have any spans or event defined in your application? If you only have spans, then FmtSubscriber will, by default, not emit anything. Try adding an event or setting FmtSubscriberBuilder::with_span_events.

[davidbarsky]

If I'm understanding you correctly, someone recently had a similar issue in Discord, where they were trying to use the tracing over FFI. This is, unfortunately, not a supported use-case, as there is no way to share a subscriber between two libraries that were compiled separately. I'd suggest giving the (dynamically-loaded library, I assume) its own Subscriber.

(Is that what you mean by FFI? Can you share how these different libraries are being loaded?)

[veeshi]

Essentially we have a core rust library which uses the tracing macros for logging.

The core rust library is then extended for different use cases using Rust wrapper libraries which expose certain FFI functions and are then compiled to a dylib for use with external C libraries.

The rust wrapper libraries are where tracing is initialised.

[davidbarsky]

I am 99% percent sure that you are saying that you are not seeing any logging come from the core Rust library that is then compiled as dylib. Is that correct? If so, then this is an unsupported use-case, as the core Rust library and Rust wrapper libraries have totally separate statics (that correspond to where each event and span will dispatch to—this is necessary for performance) and I'm not sure whether it's possible to share those statics between code that was compiled separately.

I suggest initializing a subscriber in the core library and the wrapper libraries and trying to tie spans and events together out-of-band. I'm not sure how your libraries interact or work, but to emphasize a point, tracing gets a little funky when used across code that is compiled separately, and historically, most people tied together context using something like opentelemetry.

[veeshi]

Just to clarify we aren't seeing any logs for both the core Rust library and the Rust wrapper libraries and the core rust library is compiled as a rlib and the wrapper libraries are either compiled to a dylib or cdylib depending on the use case.

As per your suggestion I've attempted to initialise tracing separately (using a blocking rolling file appender) in both libraries to separate destinations but the log files are still not being created.

[davidbarsky]

As per your suggestion I've attempted to initialise tracing separately (using a blocking rolling file appender) in both libraries to separate destinations but the log files are still not being created.

Gotcha. Unfortunately, I don't know what the issue is, and I'd need to see the code in question before I can actually say what the issue is.

(Sorry, I didn't realize I didn't post a response here—this was sitting, unfinished, in a tab for a week...)