-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
podman-remote exec return codes incorrect #6893
Comments
Working on this now. Think it might be a race between Podman reading the exit code from Conmon and the client doing an inspect to get exit status. |
It is definitely a race, but not what I originally thought. Seems specific to exec sessions that exit instantly. |
Interestingly, something like |
@mheon, Just for the sake of dotting every 't', I want to provide precise full context here. The problem as reported is only with two specially-defined cases of podman and docker execution: running a directory, and running a nonexistent command. Exact setup follows: In window 1: $ ./bin/podman system service --timeout=0 In window 2: $ ./bin/podman-remote run -d --name foo alpine sleep 60
776787db6f7824763cdcb6db6b8953a716e995a356003151c799bf48ea8cefb1
$ for i in true false /etc no-such-command;do ./bin/podman-remote exec foo $i;echo $?;echo;done
0
1
open executable: Operation not permitted: OCI runtime permission denied error
0 <--- bad: should be 126
executable file not found in $PATH: No such file or directory: OCI runtime command not found error
0 <--- bad: should be 127 Meanwhile, back in window 1, the following two error messages are seen (for the last two cases respectively):
|
Thanks, @mheon! I did not find/take the time to tackle it. |
@edsantiago Thanks, that helped a lot. I think I have a fix now, doing some tests before I make a PR. |
In local Podman, the frontend interprets the error and exit code given by the Exec API to determine the appropriate exit code to set for Podman itself; special cases like a missing executable receive special exit codes. Exec for the remote API, however, has to do this inside Libpod itself, as Libpod will be directly queried (via the Inspect API for exec sessions) to get the exit code. This was done correctly when the exec session started properly, but we did not properly handle cases where the OCI runtime fails before the exec session can properly start. Making two error returns that would otherwise not set exit code actually do so should resolve the issue. Fixes containers#6893 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
In local Podman, the frontend interprets the error and exit code given by the Exec API to determine the appropriate exit code to set for Podman itself; special cases like a missing executable receive special exit codes. Exec for the remote API, however, has to do this inside Libpod itself, as Libpod will be directly queried (via the Inspect API for exec sessions) to get the exit code. This was done correctly when the exec session started properly, but we did not properly handle cases where the OCI runtime fails before the exec session can properly start. Making two error returns that would otherwise not set exit code actually do so should resolve the issue. Fixes containers#6893 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Several integration tests that are current disabled review that podman-remote sets exit codes of 0 when commands have failed.
exec foobar /etc should return a 126 (returns 0 today)
exec foobar notarealcommand should return a 127 (returns 0 today)
These can be verified with exec_test.go: 229 and :240
The text was updated successfully, but these errors were encountered: