wavetermdev/waveterm · error

process group id not supported on windows

Error message

process group id not supported on windows

What it means

GetProcessGroupId is the Windows stub of a cross-platform unixutil API; process group IDs are a POSIX concept (getpgid) with no Windows equivalent, so the stub unconditionally returns this error. Any code path calling it on a Windows build will always fail.

Source

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

// Copyright 2026, Command Line Inc.
// SPDX-License-Identifier: Apache-2.0

//go:build windows

package unixutil

import (
	"fmt"
	"os"
)

func GetProcessGroupId(pid int) (int, error) {
	return 0, fmt.Errorf("process group id not supported on windows")
}

func ParseSignal(sigName string) os.Signal {
	return nil
}

func GetSignalName(sig os.Signal) string {
	if sig == nil {
		return ""
	}
	return sig.String()
}

func SetCloseOnExec(fd int) {
}

func SignalTerm(pid int) error {
	proc, err := os.FindProcess(pid)

View on GitHub (pinned to a4447c1563)

Solutions

1. Gate the call behind runtime.GOOS != "windows" (or a !windows build tag) and provide a Windows-appropriate alternative
2. On Windows, use the Job Object API or process tree enumeration instead of POSIX process groups if grouping is actually required
3. Degrade gracefully: treat "group id unavailable" as a non-fatal condition when the caller only needs it for signal-broadcast features
4. Refactor call sites to depend on an interface with platform implementations so unsupported operations are explicit

Example fix

// before
pgid, err := unixutil.GetProcessGroupId(pid) // always errors on windows
// after
if runtime.GOOS == "windows" {
    // skip group-based logic; signal the single pid directly
    return unixutil.SendSignalByName(pid, "SIGTERM") // or handle per-OS
}
pgid, err := unixutil.GetProcessGroupId(pid)

if runtime.GOOS == "windows" {
    return errors.New("process group id unavailable on windows")
}

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

pgid, err := unixutil.GetProcessGroupId(pid)
if err != nil && strings.Contains(err.Error(), "not supported on windows") {
    pgid = pid // fallback: treat pid as its own group / skip grouping
}

When it happens

Trigger: Calling GetProcessGroupId on a Windows build of the codebase — e.g. job-control or remote-process code that assumes Unix semantics without a GOOS check or build tag.

Common situations: Cross-platform tools that compile everywhere but test signal/job-control paths only on Linux/macOS; CI runs on Windows revealing the stub; developers porting POSIX process-management code to Windows.

Related errors

• sending signals is not supported on Windows
• procinfo: process not found
• failed to run app: %w
• failed to setsid: %w
• daemonize not supported on windows

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