stalwartlabs/stalwart · error · io::Error(NotFound)

journald does not exist in this environment

Error message

journald does not exist in this environment

What it means

Constructing the journald tracer on a non-Unix platform is unsupported: journald is a Linux/systemd facility, so `new` returns an io::Error of kind NotFound. It cannot talk to the journald socket, so the tracer cannot be created at all.

Source

Thrown at crates/common/src/telemetry/tracers/journald.rs:205

            let socket = UnixDatagram::unbound()?;
            let sub = Self {
                socket,
                syslog_identifier: std::env::current_exe()
                    .ok()
                    .as_ref()
                    .and_then(|p| p.file_name())
                    .map(|n| n.to_string_lossy().into_owned())
                    // If we fail to get the name of the current executable fall back to an empty string.
                    .unwrap_or_default(),
                priority_mappings: PriorityMappings::new(),
            };
            // Check that we can talk to journald, by sending empty payload which journald discards.
            // However if the socket didn't exist or if none listened we'd get an error here.
            sub.send_payload(&[])?;
            Ok(sub)
        }
        #[cfg(not(unix))]
        Err(io::Error::new(
            io::ErrorKind::NotFound,
            "journald does not exist in this environment",
        ))
    }

    /// Sets how [`tracing_core::Level`]s are mapped to [journald priorities](Priority).
    ///
    pub fn with_priority_mappings(mut self, mappings: PriorityMappings) -> Self {
        self.priority_mappings = mappings;
        self
    }

    /// Sets the syslog identifier for this logger.
    ///
    /// The syslog identifier comes from the classic syslog interface (`openlog()`
    /// and `syslog()`) and tags log entries with a given identifier.
    /// Systemd exposes it in the `SYSLOG_IDENTIFIER` journal field, and allows
    /// filtering log messages by syslog identifier with `journalctl -t`.

View on GitHub (pinned to e962003857)

Solutions

1. Switch the telemetry tracer to a supported output (e.g. log file, stdout) on non-Unix platforms.
2. Run the service on Linux/systemd if journald output is required.
3. Gate journald selection in configuration per-platform at deployment time.

Example fix

// before (config.toml)
[telemetry.tracer.journald]
enabled = true // on Windows
// after (config.toml)
[telemetry.tracer.file]
enabled = true
path = "/var/log/stalwart"

// pick tracer per platform at startup
let tracer = if cfg!(unix) { journald_tracer() } else { file_tracer().await };

fn journald_supported() -> bool { cfg!(unix) }

let tracer = match Journald::new() {
    Ok(t) => t,
    Err(e) => { log::warn!("journald unavailable ({e}); using file tracer"); file_tracer().await },
};

When it happens

Trigger: Calling journald tracer `new()` (e.g. while initializing telemetry) compiled for non-Unix targets — the #[cfg(not(unix))] branch unconditionally returns this error.

Common situations: Running Stalwart on Windows with journald selected as telemetry tracer; cross-compiling and shipping a build with journald enabled in config.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors

• journald not supported on non-Unix
• Invalid LOG level
• Missing span ID

AI-assisted analysis of stalwartlabs/stalwart@e962003857 (2026-09-06). Data as JSON: /api/errors/909b4450f10d8eb3. Report an issue: GitHub.