This allows us to run both the Libpod and Server handlers at the
same time without unregistering one.
Also, pass the signal that killed us into the handlers, in case
they want to use it to determine what to do (e.g. what exit code
to set).
Signed-off-by: Matthew Heon <mheon@redhat.com>
we need to alter the return error message when a GET (inspect) is performed on an image using the compatibility layer. docker-py bindings look for a initial capped error message.
Signed-off-by: baude <bbaude@redhat.com>
***Warning***: `skip` has non-obvious side-effects vs `only_if`:
https://cirrus-ci.org/guide/writing-tasks/#conditional-task-execution
The skip instruction can give a false sense of security by always
marking tasks as passed in the UI, even if they didn't run. In
contrast, the `only_if` condition will avoid creating the task
all -together; therefore, a problematic task's absense is more likely to
be noticed if it introduced a problem.
Signed-off-by: Chris Evich <cevich@redhat.com>
Expand the use of the Shutdown package such that we now use it
to handle signals any time we run Libpod. From there, add code to
container creation to use the Inhibit function to prevent a
shutdown from occuring during the critical parts of container
creation.
We also need to turn off signal handling when --sig-proxy is
invoked - we don't want to catch the signals ourselves then, but
instead to forward them into the container via the existing
sig-proxy handler.
Fixes#7941
Signed-off-by: Matthew Heon <mheon@redhat.com>
CI discovered that a lot of networking tests are failing; my
fault, for not having run my tests as root on my laptop.
Disable those.
Also: bump up the ten-request time limit, from 5 to 7 seconds.
Looks like something keeps getting slower and slower, but I
guess there's not much we can do about it.
Also: when we get a mismatch response code (e.g. 500 when we
expect 200), dump the response body and skip any subsequent
response checks.
Signed-off-by: Ed Santiago <santiago@redhat.com>
We need a unified package for handling signals that shut down
Libpod and Podman. We need to be able to do different things on
receiving such a signal (`system service` wants to shut down the
service gracefully, while most other commands just want to exit)
and we need to be able to inhibit this shutdown signal while we
are waiting for some critical operations (e.g. creating a
container) to finish. This takes the first step by defining the
package that will handle this.
Signed-off-by: Matthew Heon <mheon@redhat.com>
Initially filed as #7967 but that has run into huge complicated
snags related to Ubuntu and environment.
It is crucial to get system tests working with podman-local.
It is less important to get them on Ubuntu. Let's please
expedite this PR while we settle the Ubuntu stuff in #7967
Signed-off-by: Ed Santiago <santiago@redhat.com>
In the new-Cirrus transition, APIv2 tests were inadvertently
disabled. As expected when tests get disabled, they break.
This commit fixes some failing tests, and comments out others
(with big FIXMEs) because I have neither the expertise nor
time to figure out the real problems.
The big change to test-apiv2 is due to a recently-added
test that looks for an '=' sign in json output. My '=' vs '~'
detector completely barfed on that, and there's just no
way to make it work in a bash 'case' statement. So, switch
to an 'if' with 'expr'.
And, unrelated, fix a longstanding (harmless) bug that was
issuing spurious "expected" messages to the test log; those
should've been going to the full results log.
Signed-off-by: Ed Santiago <santiago@redhat.com>
We were only including the CNI Network fields in the output of
`podman inspect` when the container was not running. It's simple
enough to fix (populate with empty structs, since we can't fill
anything without a CNI response to get IP address assigned, etc).
This is necessary for Docker compatibility.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
When we try, but fail, to load the default seccomp profile, say that,
instead of suggesting that we tried to load a profile with no name.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Previously, the order of OCI error messages was reversed, so that the
type of error was listed as the cause. For example:
Error: writing file `cpu.cfs_quota_us`: Invalid argument: OCI runtime error
This error message makes it seem like "OCI runtime error" is the
argument that was invalid. In fact, "OCI runtime error" is the error and
"writing file ..." is the cause. With this change, the above message
reads:
Error: OCI runtime error: writing file `cpu.cfs_quota_us`: Invalid argument
Signed-off-by: Jordan Christiansen <xordspar0@gmail.com>
In the past, Toolbox[0] has been affected by several of Podman's
bugs/changes of behaviour. This is one of the steps to assure that as
Podman progresses, Podman itself and subsequently Toolbox do not regress.
One of the other steps is including Toolbox's system tests in Podman's
gating systems (which and to what extent is yet to be decided on).
The tests are trying to stress parts of Podman that Toolbox needs for
its functionality: permission to handle some system files, correct
values/permissions/limits in certain parts, management of users and
groups, mounting of paths,.. The list is most likely longer and
therefore more commits will be needed to control every aspect of the
Toolbox/Podman relationship :).
Some test cases in test/e2e/toolbox_test.go rely on some tools being
present in the base image[1]. That is not the case with the common
ALPINE image or the basic Fedora image.
Some tests might be duplicates of already existing tests. I'm more in
favour of having those duplicates. Thanks to that it will be clear what
functionality/behaviour Toolbox requires.
[0] https://github.com/containers/toolbox
[1] https://github.com/containers/toolbox/#image-requirements
Signed-off-by: Ondřej Míchal <harrymichal@seznam.cz>
Currenly if a user specifies the name or ID of an external storage
container, we report an error to them.
buildah from scratch
working-container-2
podman rm working-container-2
Error: no container with name or ID working-container-2 found: no such container
Since the user specified the correct name and the container is in storage we
force them to specify --storage to remove it. This is a bad experience for the
user.
This change will just remove the container from storage. If the container
is known by libpod, it will remove the container from libpod as well.
The podman rm --storage option has been deprecated, and removed from docs.
Also cleaned documented options that are not available to podman-remote.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Following commands:
* systemd generate
* networks inspect
* pod stats
* Fixed test where format was quoted and then quoted again
* Fixed bug where output never printed '--' on missed reads
* pod ps
Signed-off-by: Jhon Honce <jhonce@redhat.com>
