opensource/podman
1
0
Fork 0
mirror of https://github.com/containers/podman.git synced 2025-07-31 12:22:29 +08:00
Code Issues Packages Projects Releases Wiki Activity

remote kill: don't wait for the container to stop

Browse Source 
Invert the branch logic to match the comment.  Docker seems to wait for
the container while Podman does not.

Enable the remote-disabled system test as well.

Fixes: #7135
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
This commit is contained in:
Valentin Rothberg
2020-09-09 14:26:45 +02:00
parent 6b1a1fcc5c
commit fce2eaa6ca
2 changed files with 1 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
pkg/api/handlers/compat/containers.go
View File

@ -174,7 +174,7 @@ func KillContainer(w http.ResponseWriter, r *http.Request) {
utils.Error(w, "Something went wrong.", http.StatusInternalServerError, errors.Wrapf(err, "unable to kill Container %s", name)) utils.Error(w, "Something went wrong.", http.StatusInternalServerError, errors.Wrapf(err, "unable to kill Container %s", name))
} }
if utils.IsLibpodRequest(r) { if !utils.IsLibpodRequest(r) {
// the kill behavior for docker differs from podman in that they appear to wait // the kill behavior for docker differs from podman in that they appear to wait
// for the Container to croak so the exit code is accurate immediately after the // for the Container to croak so the exit code is accurate immediately after the
// kill is sent. libpod does not. but we can add a wait here only for the docker // kill is sent. libpod does not. but we can add a wait here only for the docker

2
test/system/130-kill.bats
View File

@ -6,8 +6,6 @@
load helpers load helpers
@test "podman kill - test signal handling in containers" { @test "podman kill - test signal handling in containers" {
skip_if_remote "FIXME: pending #7135"
# podman-remote and crun interact poorly in f31: crun seems to gobble up # podman-remote and crun interact poorly in f31: crun seems to gobble up
# some signals. # some signals.
# Workaround: run 'env --default-signal sh' instead of just 'sh' in # Workaround: run 'env --default-signal sh' instead of just 'sh' in