uutils/coreutils · warning · std::io::Error
kill-error-unsupported-signal
Error message
kill-error-unsupported-signal
What it means
On Windows, `kill` cannot deliver stop-type signals (SIGNAL_STOP, sig 19); `send_signal` returns `io::ErrorKind::Unsupported` with the localized `kill-error-unsupported-signal` message. The platform simply has no equivalent mechanism implemented.
Solutions
- Guard the signal choice by platform: skip STOP/TSTP signals on Windows
- Use `kill -9` (SIGKILL termination) instead of STOP when suspension is not required
- Restrict the script to Unix, or use a Windows-native suspend mechanism (e.g. DebugActiveProcess-based tools)
- Handle the error gracefully: check `err.kind() == ErrorKind::Unsupported` and warn instead of failing
Example fix
// before kill -STOP $pid // after if [ "$(uname)" = "Windows_NT" ]; then echo "STOP unsupported on Windows" >&2; else kill -STOP $pid; fi
Defensive patterns
Strategy: validation
Validate before calling
# fail early on unsupported signals
[[ "$sig" == 19 || "$sig" == STOP || "$sig" == TSTP ]] && [ "$(uname)" = Windows_NT ] && { echo "sig unsupported" >&2; exit 2; } Type guard
fn is_stop_signal(sig: usize) -> bool { sig == 19 } // gate before calling send_signal Try / catch
match kill_result {
Err(e) if e.kind() == io::ErrorKind::Unsupported => {
eprintln!("signal {sig} is not supported on this platform");
}
r => r?,
} Prevention
- Never hardcode Unix-only signals (STOP/TSTP/CONT) in cross-platform scripts
- Check cfg!(windows) before issuing stop signals
- Prefer SIGKILL/SIGTERM, which have Windows equivalents, when possible
- Centralize signal constants in one platform-aware module
When it happens
Trigger: Calling `kill -19 <pid>` / `kill -STOP` / `kill -TSTP` on Windows, or invoking `send_signal(pid, 19)` via the Windows code path.
Common situations: Shell scripts ported from Unix that suspend/resume jobs with STOP/CONT, cross-platform build scripts using `kill -STOP`, or CI jobs that run Unix scripts on Windows runners.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
AI-assisted analysis of uutils/coreutils@92995feca2 (2026-09-20).
Data as JSON: /api/errors/7724ac181ffbc786.
Report an issue: GitHub.
Appendix: source
Thrown at src/uu/kill/src/platform/windows.rs:22
// file that was distributed with this source code.
// spell-checker:ignore pids
//! Windows implementation of `kill`'s platform facade, built on the signal
//! emulation in [`uucore::process`]. PID 0 targets the Job object `kill` runs
//! in, the closest Windows analog of a process group. STOP (no process-suspend
//! API) and negative pids (no way to name another process's group) are
//! rejected.
use std::io;
use uucore::process::{enable_debug_privilege, send_signal_to_own_group, send_signal_to_pid};
use uucore::translate;
const SIGNAL_STOP: usize = 19;
fn unsupported(message: String) -> io::Error {
io::Error::new(io::ErrorKind::Unsupported, message)
}
pub(crate) fn send_signal(pid: i32, sig: usize) -> io::Result<()> {
if sig == SIGNAL_STOP {
return Err(unsupported(translate!("kill-error-unsupported-signal")));
}
match u32::try_from(pid) {
// Fails exactly for pid < 0.
Err(_) => Err(unsupported(translate!(
"kill-error-negative-pid-unsupported"
))),
Ok(pid) => {
// Group members need the same rights as a single target.
enable_debug_privilege();
if pid == 0 {
send_signal_to_own_group(sig)
} else {
send_signal_to_pid(pid, sig)View on GitHub (pinned to 92995feca2)