Any way to detect the closing of stdout to disable the stdout sink?

[Ymif-Jordan]

Hi, I am writing a program that uses both the stdout and a file sink. The stdout sink is used for seeing the startup logging to make sure the program starts correctly (with the right config etc.) as well as monitoring things as it is running. The process is always started detached in the shell. However, once we are done monitoring we log out of our ssh session, thus closing the stdout stream. Which immediately makes the process panic on the next log printed to stdout.

I am wondering if there is some way of detecting whether the stdout stream was closed so I can disable the stdout sink when that happens. Or is there perhaps a better way?

[SpriteOvO]

Hi @Ymif-Jordan, could you tell me the command you are using to start a detached program from shell? Which shell are you using? I'd like to reproduce the problem on my machine.

[Ymif-Jordan]

Hi, I am using sh:

~# echo $0
-sh

For starting the program I just append an & to the command:

~# ./spdlog-stdout-test &

If it helps: from what I've been able to find online in Rust print!() and println!() will panic if the stream they are writing to is closed. I've looked around a bit at the spdlog-rs source code but couldn't find any print or write statements in my quick search. In any case, write!() and writeln!() return the Err():

Os { code: 5, kind: Uncategorized, message: "I/O error" }

[Ymif-Jordan]

This is the small program I ran to test it on its own:

use spdlog::prelude::*;
fn main() -> anyhow::Result<()> {
    loop {
        info!("test");
        sleep(Duration::from_millis(3000));
    }
}

I have 2 ssh sessions running, in one I have htop opened to watch the process panic in real time and in the other I start the process with an & and logout of the ssh session.

[SpriteOvO]

I have reproduced it and found out the reason:

After an ssh session is disconnected, the pty will be closed, thus any write to its stdout/stderr will return errors. StdStreamSink handles these errors well. However, if a sink does not have an error handler set up, the default error handler will be called. In the currently implementation, the default error handler uses eprintln! to write the error to stderr (code), and the eprintln! causes a panic in the situation.

Good catch! I will fix it soon.

[SpriteOvO]

I have opened a PR #88 to fix the panic, could you test if it works for you?

However, in your case, each log will still do an absolute failure stdio write, which will have some performance overhead. And I suspect there's no clean way to detect broken stdio. If I were you, I would make a systemd service for this program and just do systemctl status my-program or journalctl -ru my-program to monitor its startup logging.

[Ymif-Jordan]

It no longer crashes after closing the ssh session with PR #88 ! Thanks.

I did indeed set up systemd services for our programs already, seemed like an elegant solution.

Thank you for your time and help in solving this issue.

[SpriteOvO]

I have released v0.4.2 for the fix, it's available on crates.io now.