summaryrefslogtreecommitdiff
path: root/test/system/130-kill.bats
Commit message (Collapse)AuthorAge
* remote kill: don't wait for the container to stopValentin Rothberg2020-09-09
| | | | | | | | | | 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>
* Reenable remote system testsEd Santiago2020-08-03
| | | | | | | | | | | | | | | | | | | podman-remote is in better shape now. Let's see what needs to be done to reenable remote system tests. - logs test: skip multilog, it doesn't work remote - diff test: use -l only when local, not with remote - many other tests: skip_if_remote, with 'FIXME: pending #xxxx' where xxxx is a filed issue. Unrelated: added new helper to skip_if_remote and _if_rootless, where we check if the source message includes "remote"/"rootless" and insert it if missing. This is a minor usability enhancement to make it easier to understand at-a-glance why a skip triggers. Signed-off-by: Ed Santiago <santiago@redhat.com>
* Switch all references to github.com/containers/libpod -> podmanDaniel J Walsh2020-07-28
| | | | Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
* kill test: clean up warnings; document betterEd Santiago2020-02-26
| | | | | | | | | | | | | | | | | | | 9f69c4eca (part of the f31 pr, #3091) semi-broke the kill test, there's now an ugly warning: setup(): removing stray images quay.io/libpod/fedora-minimal:latest 7bb5a60e8a78 The comments also didn't actually explain the problem being addressed, and included a misleading reference to busybox. Here we switch to using fedora-minimal only with podman-remote, clean it up (rmi) when finished, and include an explanation in the comments about why this is needed; making it clear that this workaround can be removed once we get rid of podman-remote. We also reformat back to 80 columns. Signed-off-by: Ed Santiago <santiago@redhat.com>
* Fix kill test obtaining CIDChris Evich2020-02-25
| | | | | | | | | | It's possible/likely the container image for the test will need to be pulled as part of the `run` command. Due to the way BATS handles output, messages regarding image-pull could be misinterpreted as the container's CID. Force the CID to be obtained by only the last line of output. Signed-off-by: Chris Evich <cevich@redhat.com>
* System Tests: Force default signal handlersChris Evich2020-02-25
| | | | | | | | | | | Recommended as part of: https://github.com/containers/libpod/issues/5004 and https://github.com/containers/crun/issues/230 Signed-off-by: Chris Evich <cevich@redhat.com>
* add pkg/signalValentin Rothberg2020-02-14
| | | | | | | | | Add pkg/signal to deal with parts of signal processing and translating signals from string to numeric representations. The code has been copied from docker/docker (and attributed with the copyright) but been reduced to only what libpod needs (on Linux). Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Fix race condition in kill test leading to hangEd Santiago2019-12-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you open a FIFO for reading, but there's no writer, you hang. This is just one of those obscure UNIXisms we all know but just forget all too often. My last PR was guilty of introducing such a condition; I caught it by accident while testing other stuff. In short, the signal container was doing 'echo DONE' as its last step, and we (BATS) were reading the FIFO to check for it; but if the container exited before we opened the FIFO for read, the open would hang. This is not a hang that we can catch in the test: it would hang the entire job forever. CI would presumably time out eventually, but with no useful indication of the cause of the error. Solution: use 'exec' to open the FIFO early and keep it open, and use 'read -u FD' instead of 'read <$fifo': the former reads from an open FD, the latter forces a new open() each time. There is a shorter, more maintainable solution -- see #4755 -- but that suffers from the same hanging problem in the (unlikely) case where the signal-handling container exits, e.g. if signal handling is broken in podman. The test would hang, with no helpful indicator. Although this PR is a little more advanced scripting, I have commented the relevant code well and believe the maintenance cost is worth the risk of undebuggable hangs. There is still a hang risk: if 'podman logs -f' fails and exits immediately, the 'exec' will hang. I can't think of a non-racy way to prevent that, and choose to live with that risk. Tested by temporarily including 9 (SIGKILL) in the signals list. The read timeout triggers, and the end user has a fair chance of tracking down the root cause. Signed-off-by: Ed Santiago <santiago@redhat.com>
* signal parsing - better input validationEd Santiago2019-12-26
The helper function we use for signal name mapping does not check for negative numbers nor invalid (too-high) ones. This can yield unexpected error messages: # podman kill -s -1 foo ERRO[0000] unknown signal "18446744073709551615" This PR introduces a small wrapper for it that: 1) Strips off a leading dash, allowing '-1' or '-HUP' as valid inputs; and 2) Rejects numbers <1 or >64 (SIGRTMAX) Also adds a test suite checking signal handling as well as ensuring that invalid signals are rejected by the command line. Fixes: #4746 Signed-off-by: Ed Santiago <santiago@redhat.com>