-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
MacOS + PHP + proc_open('docker-compose (v2)') = read /dev/stderr: bad file descriptor
#9115
Comments
Does invoking Also, does invoking Compose V2 as a CLI plugin (i.e. |
@xenoscopic ➜ ~/.../ComposeV2 $ php dc2test.php
bin
boot
dev
[...]
tmp
usr
var
0%
➜ ~/.../ComposeV2 $ php dc2test.php
bin
boot
dev
[...]
usr
var
0%
|
I see "interesting" behavior like this from docker-compose v2.2.2 or docker-compose v2.2.3 with calling code like this: proc := exec.Command(path, arg...)
proc.Stdout = stdout
proc.Stdin = stdin
proc.Stderr = stderr
err = proc.Run() It's calling Related Stack Overflow link: https://stackoverflow.com/questions/20134095/why-do-i-get-bad-file-descriptor-in-this-go-program-using-stderr-and-ioutil-re |
I seem to be past this. I note now that it was happening when debugging in Goland, so could be possible that Goland or delve does something funky to stderr. But I do suspect that since this has been discovered in various contexts that it's misbehavior from composer when something has happened to stderr, or perhaps the issue in the stack overflow posting. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically closed because it had not recent activity during the stale period. |
Description
Docker-compose v2 does something to stderr on macOS. We're using Monterey / Darwin / Intel, 12.1 (21C52), kernel 21.2.0 as our operating system, and Docker Desktop with a project with some Docker containers, tied together through (during development) multiple docker-compose.yml files. It repros with one compose file as well.
Steps to reproduce the issue:
This is, very simplified, what Symfony's Process component does when you start a process. This Process in turn is instantiated by Deployer, used to execute commands locally and in a container.
Describe the results you received:
When the checkbox for "Use Docker Compose V2" is off, it works fine. Always has. You'll get a nice directory listing of the entrypoint of the mysql container (or the output of whatever other command you executed on whatever container), followed by the exit code of "0%".
However, when you do check the V2 checkbox in Docker Desktop and apply, you will still get the same output, but now it'll be followed by:
This trips the Process component into thinking the execution of the command failed. It didn't, I can see long-running commands being started within the container, but the caller doesn't know that.
Describe the results you expected:
I would expect
docker-compose
in V2 mode not to give errors about /dev/stderr being a bad file descriptor.Additional information you deem important (e.g. issue happens only occasionally):
This was ultimately discovered by our use of a filesystem syncing tool called Mutagen, which recently released v0.13.0 out of beta, which now exclusively uses Compose V2.
Output of
docker compose version
:With V2 checkbox off (and
docker-compose
, notdocker compose
):Output of
docker info
:Workarounds
mutagen-compose
which is now irrevocably a V2 wrapper.['file', '/dev/tty', 'w'], // stderr
to .../dev/null, but then we won't get error output, and also, the code that builds that array is outside of our control.The text was updated successfully, but these errors were encountered: