Skip to content
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

Closed
baude opened this issue Jul 7, 2020 · 6 comments · Fixed by #7236
Closed

podman-remote exec return codes incorrect #6893

baude opened this issue Jul 7, 2020 · 6 comments · Fixed by #7236
Assignees
Labels
HTTP API Bug is in RESTful API kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@baude
Copy link
Member

baude commented Jul 7, 2020

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

@mheon
Copy link
Member

mheon commented Aug 3, 2020

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.

@mheon mheon added HTTP API Bug is in RESTful API kind/bug Categorizes issue or PR as related to a bug. labels Aug 3, 2020
@mheon
Copy link
Member

mheon commented Aug 3, 2020

It is definitely a race, but not what I originally thought. Seems specific to exec sessions that exit instantly.

@mheon
Copy link
Member

mheon commented Aug 3, 2020

Interestingly, something like ls /desnotexist does not trigger it - but exit 1 does.

@edsantiago
Copy link
Member

@mheon, exit 1 triggers the error but only because there is no exit command. exec sh -c "exit 5" exits 5 as expected.

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):

ERRO[0392] Error attaching to container 776787db6f7824763cdcb6db6b8953a716e995a356003151c799bf48ea8cefb1 exec session 4f91602528aa287febb160648a05eec3a6b8642b94065163963390533bd5e1ee: open executable: Operation not permitted: OCI runtime permission denied error
ERRO[0392] Error attaching to container 776787db6f7824763cdcb6db6b8953a716e995a356003151c799bf48ea8cefb1 exec session 23251cc3fe750ca944a735f0c90c82a5f0a19d8d758bcdcd4ed5e1861f9aef11: executable file not found in $PATH: No such file or directory: OCI runtime command not found error

@vrothberg vrothberg removed their assignment Aug 4, 2020
@vrothberg
Copy link
Member

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.

Thanks, @mheon! I did not find/take the time to tackle it.

@mheon
Copy link
Member

mheon commented Aug 5, 2020

@edsantiago Thanks, that helped a lot.

I think I have a fix now, doing some tests before I make a PR.

mheon added a commit to mheon/libpod that referenced this issue Aug 5, 2020
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>
vrothberg pushed a commit to vrothberg/libpod that referenced this issue Aug 11, 2020
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>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
HTTP API Bug is in RESTful API kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants