8000 [Process] `Error: proc_open(): posix_spawn() failed: No such file or directory in /app/vendor/symfony/process/Process.php:371` · Issue #57722 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[Process] Error: proc_open(): posix_spawn() failed: No such file or directory in /app/vendor/symfony/process/Process.php:371 #57722

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ToshY opened this issue Jul 14, 2024 · 7 comments

Comments

@ToshY
Copy link
Contributor
ToshY commented Jul 14, 2024

Symfony version(s) affected

7.1

Description

Upgrading symfony/process from 7.0.8 to 7.1.1 breaks commiting with phpro/grumphp:^2.0.

$ git commit -m 'wip'

Fatal error: Uncaught Symfony\Component\Process\Exception\ProcessStartFailedException: The command "'git' 'rev-parse' '--show-toplevel'" failed.

Working directory: /app

Error: proc_open(): posix_spawn() failed: No such file or directory in /app/vendor/symfony/process/Process.php:371
Stack trace:
#0 /app/vendor/symfony/process/Process.php(249): Symfony\Component\Process\Process->start(NULL, Array)
#1 /app/vendor/phpro/grumphp/src/Locator/GitWorkingDirLocator.php(31): Symfony\Component\Process\Process->run()
#2 /app/vendor/phpro/grumphp/src/Locator/GuessedPathsLocator.php(158): GrumPHP\Locator\GitWorkingDirLocator->locate()
#3 /app/vendor/phpro/grumphp/src/Locator/GuessedPathsLocator.php(50): GrumPHP\Locator\GuessedPathsLocator->safelyLocateGitWorkingDir('/app')
#4 /app/vendor/phpro/grumphp/src/Configuration/ContainerFactory.php(57): GrumPHP\Locator\GuessedPathsLocator->locate(NULL)
#5 /app/vendor/phpro/grumphp/src/Configuration/ContainerFactory.php(25): GrumPHP\Configuration\ContainerFactory::guessPaths(NULL)
#6 /app/vendor/phpro/grumphp/bin/grumphp(44): GrumPHP\Configuration\ContainerFactory::build(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#7 /app/vendor/phpro/grumphp/bin/grumphp(51): {closure}()
#8 /app/vendor/bin/grumphp(119): include('/app/vendor/php...')
#9 {main}
  thrown in /app/vendor/symfony/process/Process.php on line 371

How to reproduce

  • Having dependencies phpro/grumphp:^2.0 (dev) and symfony/process:7.1.*
  • Running in docker with PHP-FPM 8.3.8.

Example grumphp config

grumphp.yml

grumphp:
  process_timeout: 90
  git_hook_variables:
    EXEC_GRUMPHP_COMMAND: 'docker compose run -T --rm --no-deps phpfpm'
  tasks:
    phpcsfixer:
      config: '.php-cs-fixer.dist.php'

Possible Solution

Using 7.0.8 until fixed.

Additional Context

Possibly related to #52409

Reproduction example

https://github.com/ToshY/symfony-57722

@xabbuh
Copy link
Member
xabbuh commented Jul 14, 2024

Can you create a small example application that allows to reproduce your issue?

@nicolas-grekas
Copy link
Member

Do you have the git command available? IIRC, this might happen when git is not found.

@ToshY
Copy link
Contributor Author
ToshY commented Jul 15, 2024

@xabbuh I will try to recreate a sample application later today.

@nicolas-grekas No, the PHP-FPM image does not contain git.

$ docker run --rm -it --entrypoint=/bin/sh t0shy/phpfpm-bookworm:8.3.9 git -v
/bin/sh: 0: cannot open git: No such file

This was never an issue until I bumped symfony/process:7.1.*.

What would be the recommended approach/workaround for this, without the need of installing git in the docker image?

@xabbuh
Copy link
Member
xabbuh commented Jul 15, 2024

This then rather looks like something to handle in GrumPHP (maybe that's already configurable?). If git is not installed, looking for its working directory does not make much sense to me.

@nicolas-grekas
Copy link
Member

We need to acknowledge that the behavior changed with #52409: when a command is not available, we now know it right away and we throw a ProcessStartFailedException. Before the command always started successfully because of the sh wrapper, and exited with a non-zero status code that was easy to ignore.
Not sure if we should emulate the previous behavior?

@ToshY
Copy link
Contributor Author
ToshY commented Jul 15, 2024

@xabbuh In case it's still needed, I've created an example repo: https://github.com/ToshY/symfony-57722

@nicolas-grekas
Copy link
Member

Closing as duplicate of #57946, let's continue there.

@nicolas-grekas nicolas-grekas closed this as not planned Won't fix, can't repro, duplicate, stale Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants
0