phacility/phabricator · error · Exception

Unable to find 'sudo'!

Error message

Unable to find 'sudo'!

What it means

When a daemon must run as a different user than the launching process, PhabricatorDaemon rewrites the launch command to go through sudo (-E -n -u <user>). Filesystem::resolveBinary('sudo') searches the current PATH for the sudo binary and returns null when it cannot be found, which triggers this exception. It means the host cannot perform the privilege drop the daemon configuration requests.

Source

Thrown at src/infrastructure/daemon/PhabricatorDaemon.php:59

    // By default, `sudo` won't let you sudo to yourself, so we can get into
    // trouble if we're already running as the daemon user unless the host has
    // been configured to let the daemon user run commands as itself.

    // Since this is silly and more complicated than doing this check, don't
    // use `sudo` if we're already running as the correct user.
    if (function_exists('posix_getuid')) {
      $uid = posix_getuid();
      $info = posix_getpwuid($uid);
      if ($info && $info['name'] == $user) {
        return $command;
      }
    }

    // Get the absolute path so we're safe against the caller wiping out
    // PATH.
    $sudo = Filesystem::resolveBinary('sudo');
    if (!$sudo) {
      throw new Exception(pht("Unable to find 'sudo'!"));
    }

    // Flags here are:
    //
    //   -E: Preserve the environment.
    //   -n: Non-interactive. Exit with an error instead of prompting.
    //   -u: Which user to sudo to.

    return csprintf('%s -E -n -u %s -- %C', $sudo, $user, $command);
  }

}

View on GitHub (pinned to 5720a38cfe)

Solutions

1. Install sudo on the host (e.g. apt-get install sudo or yum install sudo).
2. If sudo is installed, make sure its directory (usually /usr/bin) is in the PATH of the process launching the daemons.
3. Alternatively launch the daemon directly as the target user so no privilege drop is needed.
4. For containers, bake sudo into the image or drop the separate daemon user.

Example fix

# before: container image has no sudo, daemon launch as daemon user fails
apt-get install -y sudo
# after: launch succeeds and re-execs via sudo -E -n -u <user> -- <command>

$sudo = Filesystem::resolveBinary('sudo');
if ($sudo === null) {
  // surface a setup problem and refuse to launch daemons as another user
}

When it happens

Trigger: Starting daemons as one user with a different target daemon user (the posix_getuid()/posix_getpwuid() check shows the mismatch) on a host where sudo is not installed or its directory is not in PATH — typical of minimal container images that omit sudo.

Common situations: Moving Phabricator into Docker/Alpine-style images that ship without sudo; hardened environments with a stripped PATH; BSD hosts where sudo lives in /usr/local/bin or /usr/local/sbin outside the daemon's PATH; chroot setups.

Related errors

• Before you can set up or use LDAP, you need to install the P
• Keyring is configured with a "%s" key, but the PHP OpenSSL e
• Unable to imagesavealpha() a new empty image: %s
• Unable to imagecolorallocatealpha() a new empty image: %s
• Unable to imagefill() a new empty image: %s

AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/1fe4521051503751. Report an issue: GitHub.