issue #7444 describes a problem where an image does not have a manifest file and cannot be processed by our library correctly. the origin of the panic is because we are checking the len of a nil object's attribute. this is a temporary fix to protect from the panic in the future. the origin of the problem is more interesting and requires more work when the code author returns from pto.
Signed-off-by: Brent Baude <bbaude@redhat.com>
Currently, subsequent runs of `make localunit` fail and complain about
prior existing /dev/shm/libpod_test and /dev/shm/test1.
This commit deletes these files if existing already, prior to running
the tests.
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
Check if storage.conf exists and display a message that
this file should be removed if it has not been modified.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
With previous versions of Podman (like v1.9.2) it was always possible to
specify the log level in any case, for example `INFO`. This behavior has
silently changed, where the `--log-level` flag only accepts lower case
levels. This commit re-enables the old behavior and adds an e2e test for
it.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
podman needs to use the environment settings in containers.conf
when setting up the containers.
Also host environment variables should be relative to server side
not the client.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Switch the libpod references to podman in the CONTRIBUTING.md.
Update the cirrus-ci link so we can get a green build again :)
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
The seccomp/containers-golang library is not maintained any more and we
should stick to containers/common.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
We have a lot of 'cannot stat %s' errors in our codebase. These
are terrible and confusing and utterly useless without context.
Add some context to a few of them so we actually know what part
of the code is failing.
Signed-off-by: Matthew Heon <mheon@redhat.com>
The APIv2 pod endpoints that operate on multiple containers, such
as Start, Kill, Pause, Unpause, do not report errors encountered
by individual containers, because they incorrectly assume that
any error is fatal. The documentation for the Libpod API calls
notes, however, that ErrPodPartialFail will *always* be returned
if any container failed; so we need to ignore that error and
continue to collating and returning container errors.
Signed-off-by: Matthew Heon <mheon@redhat.com>
The test that does 'adduser' in a keep-id container had a
really dumb bug: if the user running the test has UID 1000,
then podman itself (via keep-id) will add the "1000" passwd
entry, and the in-container "adduser" will allocate 1001,
making our test fail. This triggered in f31/f32 podman gating
tests, but (?!?) never in rawhide gating tests.
Solution: explicitly feed a UID to adduser. Make sure that
it's not the same as the UID of the current user.
Also (unrelated): fix a ridiculous "run mkdir || die". At
the time I wrote that I probably had no idea how BATS works.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Add support for multi level subcommands.
e.g. podman system connection.
Update the flags and add note for containers.conf.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
Our previous flow was to perform a hijack before passing a
connection into Libpod, and then Libpod would attach to the
container's attach socket and begin forwarding traffic.
A problem emerges: we write the attach header as soon as the
attach complete. As soon as we write the header, the client
assumes that all is ready, and sends a Start request. This Start
may be processed *before* we successfully finish attaching,
causing us to lose output.
The solution is to handle hijacking inside Libpod. Unfortunately,
this requires a downright extensive refactor of the Attach and
HTTP Exec StartAndAttach code. I think the result is an
improvement in some places (a lot more errors will be handled
with a proper HTTP error code, before the hijack occurs) but
other parts, like the relocation of printing container logs, are
just *bad*. Still, we need this fixed now to get CI back into
good shape...
Fixes#7195
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
