What causes "unsupported syslog facility: {}" in shadowsocks/shadowsocks-rust?

Set the syslog facility to a valid value 0-23 (typically 19 for LOG_LOCAL3 or another LOCAL*)

unsupported syslog facility: {}

Error message

unsupported syslog facility: {}

What it means

make_syslog_writer maps a numeric syslog facility (0-23) to the syslog crate's Facility enum and panics on any value outside that range. The facility number comes from configuration (e.g. `log-syslog-facility`); only LOG_KERN(0) through LOG_LOCAL7(23) are valid. This is a configuration validation failure at logging setup time.

Source

Thrown at src/logging/tracing.rs:209

        Some(f) => match f {
            1 => Facility::User,
            2 => Facility::Mail,
            3 => Facility::Daemon,
            4 => Facility::Auth,
            6 => Facility::Lpr,
            7 => Facility::News,
            8 => Facility::Uucp,
            9 => Facility::Cron,
            10 => Facility::AuthPriv,
            16 => Facility::Local0,
            17 => Facility::Local1,
            18 => Facility::Local2,
            19 => Facility::Local3,
            20 => Facility::Local4,
            21 => Facility::Local5,
            22 => Facility::Local6,
            23 => Facility::Local7,
            _ => panic!("unsupported syslog facility: {}", f),
        },
    };
    let options = Options::default();
    let identity = CString::new(identity).expect("syslog identity contains null-byte ('\\0')");

    match Syslog::new(identity, options, facility) {
        Some(l) => l,
        None => panic!("syslog is already initialized"),
    }
}

View on GitHub (pinned to 8eb0f0a65b)

Solutions

Set the syslog facility to a valid value 0-23 (typically 19 for LOG_LOCAL3 or another LOCAL*)
Remove the facility key to use the default facility
Consult syslog(3) facility numbering (USER=1, DAEMON=3, LOCAL0=16 ... LOCAL7=23)

Example fix

// before (config.json)
"log-syslog": 1,
"log-syslog-facility": 24
// after
"log-syslog": 1,
"log-syslog-facility": 19

Defensive patterns

Strategy: validation

Validate before calling

# validate facility in config before launch:
facility=$(jq '.log-syslog-facility // 19' config.json); [ "$facility" -ge 0 ] && [ "$facility" -le 23 ] || exit 1

Prevention

Use facility values 0-23 only, favoring LOCAL0-LOCAL7 (16-23)
Validate config with a schema check before deployment
Omit the facility key to accept the default
Cross-check facility integers against syslog(3) numbering

When it happens

Trigger: Calling make_syslog_writer (via make_layer) with a facility integer > 23 (or otherwise unmapped), e.g. `log-syslog-facility: 24` in the config when syslog logging is enabled.

Common situations: Typos in config producing the wrong number; copying facility codes from other software that uses a different numbering; assuming arbitrary integers are accepted.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

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