wavetermdev/waveterm · error

sending signals is not supported on Windows

Error message

sending signals is not supported on Windows

What it means

SendSignalByName on Windows is a stub that unconditionally returns this error: POSIX signal delivery is not implemented for the Windows build. Like the group-id stub, every call on Windows fails regardless of arguments.

Source

Thrown at pkg/util/unixutil/unixutil_windows.go:49

func SignalTerm(pid int) error {
	proc, err := os.FindProcess(pid)
	if err != nil {
		return err
	}
	return proc.Kill()
}

// this is a no-op on windows
func SignalHup(pid int) error {
	return nil
}

func IsPidRunning(pid int) bool {
	return false
}

func SendSignalByName(pid int, sigName string) error {
	return fmt.Errorf("sending signals is not supported on Windows")
}

View on GitHub (pinned to a4447c1563)

Solutions

1. Check the host OS before offering/exposing signal functionality; hide or disable the action on Windows
2. Implement Windows termination via other APIs: os.Process.Kill, GenerateConsoleCtrlEvent, or taskkill /PID
3. Return the OS limitation to the user with an actionable alternative (e.g. "force-kill supported instead")
4. Add a build-tagged Windows implementation if graceful signaling becomes a requirement

Example fix

// before
err := unixutil.SendSignalByName(pid, "SIGTERM") // errors on windows
// after
if runtime.GOOS == "windows" {
    p, perr := os.FindProcess(pid)
    if perr == nil {
        err = p.Kill() // hard kill substitute
    }
} else {
    err = unixutil.SendSignalByName(pid, "SIGTERM")
}

if runtime.GOOS == "windows" {
    return errors.New("signal delivery not available on windows; use force-kill")
}

func signalingSupported() bool { return runtime.GOOS != "windows" }

if err := unixutil.SendSignalByName(pid, sig); err != nil {
    if strings.Contains(err.Error(), "not supported on Windows") {
        p, _ := os.FindProcess(pid)
        _ = p.Kill() // windows fallback
    }
}

When it happens

Trigger: Any invocation of SendSignalByName in a Windows build — e.g. RemoteProcessSignalCommand dispatched on a Windows server, or frontend code offering a "kill process" action without checking the host OS.

Common situations: Remote terminal products whose server runs on Windows; users clicking a signal button in the UI against a Windows backend; feature flags not scoped by platform.

Related errors

• process group id not supported on windows
• unsupported or invalid signal %q
• process %d not found: %w
• procinfo: process not found
• failed to run app: %w

AI-assisted analysis of wavetermdev/waveterm@a4447c1563 (2026-09-01). Data as JSON: /api/errors/c940b92a778e0749. Report an issue: GitHub.