syncthing/syncthing · warning

get process group: %w

Error message

get process group: %w

What it means

Returned by SetLowPriority on Linux when syscall.Getpgid(0) fails while trying to discover the current process group before lowering process priority. The code comment notes this 'really shouldn't happen' — it requires a broken syscall interface. It is an environment-level anomaly, not a logic error in the caller.

Source

Thrown at lib/osutil/lowprio_linux.go:57

	// Remember Linux kernel nice levels are upside down.
	if cur, err := syscall.Getpriority(syscall.PRIO_PROCESS, 0); err == nil && cur <= wantNiceLevel {
		// We're done here.
		return nil
	}

	// Move ourselves to a new process group so that we can use the process
	// group variants of Setpriority etc to affect all of our threads in one
	// go. If this fails, bail, so that we don't affect things we shouldn't.
	// If we are already the leader of our own process group, do nothing.
	//
	// Oh and this is because Linux doesn't follow the POSIX threading model
	// where setting the niceness of the process would actually set the
	// niceness of the process, instead it just affects the current thread
	// so we need this workaround...
	if pgid, err := syscall.Getpgid(pidSelf); err != nil {
		// This error really shouldn't happen
		return fmt.Errorf("get process group: %w", err)
	} else if pgid != os.Getpid() {
		// We are not process group leader. Elevate!
		if err := syscall.Setpgid(pidSelf, 0); err != nil {
			return fmt.Errorf("set process group: %w", err)
		}
	}

	// For any new process, the default is to be assigned the IOPRIO_CLASS_BE
	// scheduling class. This class directly maps the BE prio level to the
	// niceness of a process, determined as: io_nice = (cpu_nice + 20) / 5.
	// For example, a niceness of 11 results in an I/O priority of B6.
	// https://www.kernel.org/doc/Documentation/block/ioprio.txt
	if err := syscall.Setpriority(syscall.PRIO_PGRP, pidSelf, wantNiceLevel); err != nil {
		return fmt.Errorf("set niceness: %w", err)
	}
	return nil
}

View on GitHub (pinned to 058bcd7334)

Solutions

1. Treat as non-fatal: log and continue, since low priority is an optimization, not a requirement.
2. If running under a restrictive sandbox/container, allow the getpgid syscall in the seccomp profile.
3. Verify a standard kernel/glibc combination is in use.

Example fix

// before
if err := osutil.SetLowPriority(); err != nil {
    log.Fatal(err)
}

// after
if err := osutil.SetLowPriority(); err != nil {
    log.Warn("continuing at normal priority", zap.Error(err))
}

if err := osutil.SetLowPriority(); err != nil {
    // priority is an optimization: fall back to normal priority and continue
    l.Debugln("running at normal priority:", err)
}

When it happens

Trigger: Calling osutil.SetLowPriority() in a Linux environment where getpgid returns an error (ESRCH for the self pid — essentially kernel/ABI breakage); exotic seccomp filters blocking getpgid; running under a runtime that intercepts syscalls incorrectly.

Common situations: Overly strict seccomp/sandbox profiles (gVisor, some container runtimes) that deny the getpgid syscall; otherwise practically never seen in normal operation.

Related errors

• set process group: %w
• set niceness: %w
• set niceness: %w
• get process handle: %w
• set priority class: %w

AI-assisted analysis of syncthing/syncthing@058bcd7334 (2026-08-15). Data as JSON: /api/errors/cff4df96386538f4. Report an issue: GitHub.