walkor/workerman · critical · RuntimeException

Setsid fail

Error message

Setsid fail

What it means

After the first daemonize fork, Workerman calls posix_setsid() to start a new session and release the controlling terminal. It returns -1 when the caller is already a process-group leader or when the environment (seccomp profiles, some container/sandbox configurations) disallows setsid. In the normal daemonize flow the fresh child is never a leader, so this error points at an environment restriction or an unconventional daemonize invocation.

Source

Thrown at src/Worker.php:1443

    }

    /**
     * Run as daemon mode.
     */
    protected static function daemonize(): void
    {
        if (!static::$daemonize || DIRECTORY_SEPARATOR !== '/') {
            return;
        }
        umask(0);
        $pid = pcntl_fork();
        if (-1 === $pid) {
            throw new RuntimeException('Fork fail');
        } elseif ($pid > 0) {
            exit(0);
        }
        if (-1 === posix_setsid()) {
            throw new RuntimeException("Setsid fail");
        }
        // Fork again avoid SVR4 system regain the control of terminal.
        $pid = pcntl_fork();
        if (-1 === $pid) {
            throw new RuntimeException("Fork fail");
        } elseif (0 !== $pid) {
            exit(0);
        }
    }

    /**
     * Redirect standard output to stdoutFile.
     *
     * @return void
     */
    public static function resetStd(): void
    {
        if (!static::$daemonize || DIRECTORY_SEPARATOR !== '/') {

View on GitHub (pinned to 1391112a61)

Solutions

1. Run Workerman in foreground mode (drop -d) and let the supervisor (systemd, docker, supervisord) handle daemonization
2. Loosen the seccomp/sandbox profile to allow setsid, or run in a standard container runtime
3. Avoid double-detaching: if the parent environment already daemonizes the process, do not pass -d to Workerman

Example fix

# before
php start.php start -d   # inside sandbox blocking setsid -> 'Setsid fail'

# after
# let systemd/docker detach instead
php start.php start        # foreground, supervised by the init system

When it happens

Trigger: Starting with -d inside containers/sandboxes whose seccomp policy blocks setsid; invoking Workerman's daemonize path when the process already leads a session (double-daemonize, unusual supervisors); nested process managers re-forking the master.

Common situations: Hardened Docker/gVisor/Kata sandbox profiles; running under custom supervisors that already detached the process then call Workerman with -d again.

Related errors

• Fork fail
• Bad remoteAddress
• Invalid protocol scheme '$scheme'
• class \Protocols\$scheme not exist
• Invalid protocol scheme '$scheme'

AI-assisted analysis of walkor/workerman@1391112a61 (2026-08-21). Data as JSON: /api/errors/5599e1adc9aa8ced. Report an issue: GitHub.