shadowsocks/shadowsocks-rust · error

cannot get current working directory, {err:?}

Error message

cannot get current working directory, {err:?}

What it means

The `daemonize` helper reads std::env::current_dir() and panics if it fails. Daemonizing with the Daemonize crate requires a known working directory, and shadowsocks follows shadowsocks-libev's behavior of never daemonizing with an unknown cwd. The panic is fail-fast at startup for the `-d`/daemon mode only.

Source

Thrown at src/daemonize/unix.rs:12

use std::{env::current_dir, path::Path};

use super::daemonize::Daemonize;
use log::error;

/// Daemonize a server process in a *nix standard way
///
/// This function will redirect `stdout`, `stderr` to `/dev/null`,
/// and follow the exact behavior in shadowsocks-libev
pub fn daemonize<F: AsRef<Path>>(pid_path: Option<F>) {
    let pwd = current_dir()
        .unwrap_or_else(|err| panic!("cannot get current working directory, {err:?}"))
        .canonicalize()
        .unwrap_or_else(|err| panic!("cannot get absolute path to working directory, {err:?}"));
    let mut d = Daemonize::new().umask(0).working_directory(pwd);

    if let Some(p) = pid_path {
        d = d.pid_file(p);
    }

    if let Err(err) = d.start() {
        error!("failed to daemonize, {:?} ({})", err, err);
    }
}

View on GitHub (pinned to 8eb0f0a65b)

Solutions

1. Run the binary from a directory that still exists (e.g. cd / before starting)
2. Re-create the deleted working directory or restart the process from a valid path
3. Avoid daemon mode (-d) and manage the process with systemd instead
4. Check filesystem health if paths vanish unexpectedly

Example fix

// before
shadowsocks-local -c config.json -d
# (launched from a deleted directory)
// after
cd / && shadowsocks-local -c /etc/shadowsocks/config.json -d

# ensure cwd exists before daemonizing:
cd / || exit 1; shadowsocks-server -c config.json -d

When it happens

Trigger: Calling the public `daemonize(pid_path)` in src/daemonize/unix.rs when `current_dir()` returns an error — typically because the process's current directory was deleted while the process was running, or it cannot be accessed.

Common situations: Starting the server from a directory that is later removed before daemonizing; running from a deleted tmpfs path in scripts; a wrapper script that cd's into a transient directory and then execs the binary.

Related errors

• cannot get absolute path to working directory, {err:?}
• errno
• signal
• username
• all plugins are exited. all connections may fail, check your

AI-assisted analysis of shadowsocks/shadowsocks-rust@8eb0f0a65b (2026-09-09). Data as JSON: /api/errors/437f4f077b24913d. Report an issue: GitHub.