Shut down/release log + log4rs logger so it can be reconfigured in a new PyO3 call?

I am using crates log and log4rs.

I'm trying to have a situation where my Python code (I'm using PyO3) can call the Rust Python-enabled function involved a second time, to re-run things.

I have a file logging.rs in the same directory as lib.rs which configures logging. Rust panics the second time Python calls the Rust configure_logging function, probably because some resource used in logging is unreleased. One of the 2 Appenders logs to a file, in fact does rolling logging (RollingFileAppender). This may be relevant.

I spotted that RollingFileAppender has a method flush. This might (but probably doesn't) do enough to shut things down. To set up the log4rs logger initially I do this, having built the config object:

log4rs::init_config(config)?;

I tried calling flush on the logger() object at the end of the first Rust run of the function. No change. I also tried getting the back trace, but this doesn't seem to show which line in the logging.rs file causes the problem:

stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library\std\src\panicking.rs:578
   1: core::panicking::panic_fmt
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library\core\src\panicking.rs:67
   2: core::result::unwrap_failed
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library\core\src\result.rs:1687
   3: populate_index::my_extension
   4: std::panicking::try
   5: populate_index::my_extension
    ...

Maybe the information is reduced there because I'm running this as a PyO3 module?

I'm even open to the idea that maybe the logging, once configured, will persist after my first PyO3 call has ended? And therefore, at the second call, I should just not configure, and somehow try and piggyback on to the previously set-up configuration. This seems unlikely because I have not made any provision for logging to run in its own thread or process.

Confirmation:
So having run this PyO3 module once, but not having terminated the Python app, I went to examine the current log file. I was able to open it but not to edit it: "Sharing violation". This appears to show that after leaving the PyO3 module the thread involved had not let go of the file. And yet I presume that lib4rs (or log) involve some mechanism to release resources like files at termination if just running a normal Rust module...?

Something I tried

pub fn shut_down_logging(){
    drop(logger());
}

... called just before exiting the Rust Python-callable function. Doesn't work.

Amazing!!!

I changed as follows:

// logging::configure_logging().expect("logging configure problem");
match logging::configure_logging() {
    Ok(()) => (),
    Err(e) => {
        println!("error was {e}");
    }
}
info!("Starting...");

... the second call to this module finds the existing log setup and "Starting..." is logged! NB the error message being "attempted to set a logger after the logging system was already initialized".