PHP directory attempted to be used to run PHP, instead of the binary

Hello,

I have the same problem for all my modules except the error is sh: line 1: /usr/bin: Is a directory sh: line 1: exec: /usr/bin: cannot execute: Is a directory

Did you find a solution ?

example of error
PHPStan command failed:
/usr/bin /var/www/clients/client0/web1/web/vendor/bin/phpstan analyse --memory-limit=-1 --error-format=json --configuration=sites/default/files/tmp/upgrade_status/deprecation_testing.neon /var/www/clients/client0/web1/web/modules/advagg

Command output:
Empty.

Command error:
sh: line 1: /usr/bin: Is a directory sh: line 1: exec: /usr/bin: cannot execute: Is a directory

Retitling for your specific problem.

Hello,

thank you for changing the title but does anyone have a solution for me?

I'm looking into this now.

Based on the error output, it looks like this section of the code is being returned:

        if (@is_executable($php = \PHP_BINDIR.('\\' === \DIRECTORY_SEPARATOR ? '\\php.exe' : '/php'))) {
            return $php;
        }

But for some reason `$php` is not getting the appropriate string concatenated. Actually, when reading any of the code I do not know how just a directory could be returned.

Okay, I have found a relevant item based on Laravel https://stackoverflow.com/questions/66983562/laravel-php-artisan-serve-t...

They had to set the PHP_BINARY environment variable themselves

PHP_BINARY="/opt/plesk/php/7.4/bin/php"

However, Drupal doesn't use .env files.

I still don't understand how this can be happening.

Okay, I made an MR with this change:

    // For some environments the PHP binary directory is being returned instead
    // of the binary path itself. Directories are executable, so the finder
    // is returning incorrectly. Try to fix that here.
    // @see https://github.com/symfony/symfony/issues/45620
    if (is_dir($binary)) {
      $binary .= '/php';
      if (!is_file($binary) || !is_executable($binary)) {
        throw new \Exception("The PHP binary was not found, assumed '$binary'");
      }
    }

If the PhpExecutableFinder returns a directory we try to append /php as the binary path. This matches the workaround in #3241362-18: open_basedir restrictions prevent scanning to find PHP binary

Ah nice find! Asking the folks who experienced this problem to please test this!

Added a further piece to check for is_readable() so we can cover better for open_basedir. Also made error messages more specific. Still needs manual testing by those who experience the issue.

Just ran into this issue with upgrade_status 4.0.0 on a plesk hosted website with php 8.1. So I tried the patch.

open_basedir is configured in plesk as:
{WEBSPACEROOT}{/}{:}{TMP}{/}

Error before:

The PHP binary was not found. Scanning is not possible until this is resolved.

Installed the patch

- Installing drupal/upgrade_status (4.0.0): Extracting archive
  - Applying patches for drupal/upgrade_status
    https://git.drupalcode.org/project/upgrade_status/-/merge_requests/26.diff (PHP directory attempted to be used to run PHP, instead of the binary)

Cleared caches and reloaded /admin/reports/upgrade-status

Error afterwards is the same:

The PHP binary was not found. Scanning is not possible until this is resolved.

My current workaround is similar to change the open_basedir to:
{WEBSPACEROOT}{/}{:}{TMP}{/}{:}{/}opt{/}plesk{/}php{/}8.1{/}bin{/}

I wrote a blog post about the workaround, if it helps someone: https://julian.pustkuchen.com/en/run-drupal-8-upgrade-status-module-ples...

So sadly my manual testing says, this doesn't work - at least in our case. Nor it changes the error message.

Any ideas?