Begin to separate the internal structures and frontend for
inspect on volumes. We can't rely on keeping internal data
structures for external presentation - separating presentation
and internal data format is good practice.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
There are two cases logdriver can be empty, if it wasn't set by libpod, or if the user did --log-driver ""
The latter case is an odd one, and the former is very possible and already handled for LogPath.
Instead of printing an error for an entirely reasonable codepath, let's supress the error
Signed-off-by: Peter Hunt <pehunt@redhat.com>
Add warnings/work arounds about NFS and OverlayFS to the troubleshooting guide
and also the main podman page. Verified that these warnings are on the rootless
page already.
Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
If a container is restored multiple times from an exported checkpoint
with the help of '--import --name', the restore will fail if during
'podman run' a static container IP was set with '--ip'. The user can
tell the restore process to ignore the static IP with
'--ignore-static-ip'.
Signed-off-by: Adrian Reber <areber@redhat.com>
Fedora CI tests are failing on rawhide under kernel
5.3.0-0.rc1.git3.1.fc31 (rhbz#1736758). But there's
another insidious failure, a 4-hour hang in the
rootless tests on the same CI system. The culprit
line is in the podman build test, but it's actually
BATS itself that hangs, not the build command -- which
suggests that it's the usual FD 3 problem (see BATS README).
It would seem that podman is forking a process that
inherits fd 3 but that process is not getting cleaned
up when podman crashes upon encountering the kernel bug.
Today it's podman build, tomorrow it might be something
else. Let's just run all podman invocations in run_podman
with a non-bats FD 3.
Signed-off-by: Ed Santiago <santiago@redhat.com>
close https://bugzilla.redhat.com/show_bug.cgi?id=1732280
From the bug Podman search returns 25 results even when limit option `--limit` is larger than 25(maxQueries). They want Podman to return `--limit` results.
This PR fixes the number of output result.
if --limit not set, return MIN(maxQueries, len(res))
if --limit is set, return MIN(option, len(res))
Signed-off-by: Qi Wang <qiwan@redhat.com>
This is mainly/initially to support use of Cirrus-CI
in https://github.com/containers/buildah since that setup
re-uses the VM images from this project. However, it also
opens doors here, if libpod ever needs/wants to do things
with a dedicated storage device and/or storage-drivers.
Signed-off-by: Chris Evich <cevich@redhat.com>
Somehow this managed to slip through the cracks, but this is
definitely something inspect should print.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Go 1.13.x isn't sensitive to the GO111MODULE environment variable
causing builds to not use the vendored sources in ./vendor. Force builds
of module-supporting go versions to use the vendored sources by setting
-mod=vendor.
Verified in a fedora:rawhide container.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
This enables programs and scripts wrapping the podman command to handle
'podman rm' and 'podman rmi' failures caused by paused or running
containers or due to images having other child images or dependent
containers. These errors are common enough that it makes sense to have
a more machine readable way of detecting them than parsing the standard
error output.
Signed-off-by: Ondrej Zoder <ozoder@redhat.com>
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The `$PATH` environment variable will now used as fallback if no valid
runtime or conmon path matches. The debug logs has been updated to state
the used executable.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
when running on a cgroups v2 system, do not bind mount
the named hierarchy /sys/fs/cgroup/systemd as it doesn't exist
anymore. Instead bind mount the entire /sys/fs/cgroup.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
When forcibly removing a container, we are initiating an explicit
stop of the container, which is not reflected in 'podman events'.
Swap to using our standard 'stop()' function instead of a custom
one for force-remove, and move the event into the internal stop
function (so internal calls also register it).
This does add one more database save() to `podman remove`. This
should not be a terribly serious performance hit, and does have
the desirable side effect of making things generally safer.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
We need this specifically for tests, but others may find it
useful if they don't explicitly need events and don't want the
performance implications of using them.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Podman-in-podman (and possibly ubuntu) have "issues" with
journald. Let's just use file instead to be safe.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
As we previously removed our exit code retrieval code to stop a
memory leak, we need a new way of doing this. Fortunately, events
is able to do the job for us.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
the exit file
If the container exit code needs to be retained, it cannot be retained
in tmpfs, because libpod runs in a memcg itself so it can't leave
traces with a daemon-less design.
This wasn't a memleak detectable by kmemleak for example. The kernel
never lost track of the memory and there was no erroneous refcounting
either. The reference count dependencies however are not easy to track
because when a refcount is increased, there's no way to tell who's
still holding the reference. In this case it was a single page of
tmpfs pagecache holding a refcount that kept pinned a whole hierarchy
of dying memcg, slab kmem, cgropups, unrechable kernfs nodes and the
respective dentries and inodes. Such a problem wouldn't happen if the
exit file was stored in a regular filesystem because the pagecache
could be reclaimed in such case under memory pressure. The tmpfs page
can be swapped out, but that's not enough to release the memcg with
CONFIG_MEMCG_SWAP_ENABLED=y.
No amount of more aggressive kernel slab shrinking could have solved
this. Not even assigning slab kmem of dying cgroups to alive cgroup
would fully solve this. The only way to free the memory of a dying
cgroup when a struct page still references it, would be to loop over
all "struct page" in the kernel to find which one is associated with
the dying cgroup which is a O(N) operation (where N is the number of
pages and can reach billions). Linking all the tmpfs pages to the
memcg would cost less during memcg offlining, but it would waste lots
of memory and CPU globally. So this can't be optimized in the kernel.
A cronjob running this command can act as workaround and will allow
all slab cache to be released, not just the single tmpfs pages.
rm -f /run/libpod/exits/*
This patch solved the memleak with a reproducer, booting with
cgroup.memory=nokmem and with selinux disabled. The reason memcg kmem
and selinux were disabled for testing of this fix, is because kmem
greatly decreases the kernel effectiveness in reusing partial slab
objects. cgroup.memory=nokmem is strongly recommended at least for
workstation usage. selinux needs to be further analyzed because it
causes further slab allocations.
The upstream podman commit used for testing is
1fe2965e4f (v1.4.4).
The upstream kernel commit used for testing is
f16fea666898dbdd7812ce94068c76da3e3fcf1e (v5.2-rc6).
Reported-by: Michele Baldessari <michele@redhat.com>
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
<Applied with small tweaks to comments>
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
The release-task ***must*** always execute last, in order to guarantee a
consistent cache of release archives from dependent tasks. It
accomplishes this by verifying it's task-number matches one-less than
the total number of tasks. Previous to this commit, a YAML anchor/alias
was used to avoid duplication of the dependency list between 'success'
and 'release'
However, it's been observed that this opens the possibility for
'release' and 'success' tasks to race when running on a PR. Because
YAML anchor/aliases cannot be used to modify lists, duplication is
required to make 'release' actually depend upon 'success'.
This duplication will introduce an additional maintenance burden.
Though when adding a new task, it's already very easy to forget to
update the 'depends_on' list. Assist both cases by the addition
unit-tests to verify ``.cirrus.yml`` dependency contents and structure.
Signed-off-by: Chris Evich <cevich@redhat.com>
This task depends upon other tasks caching their binaries. If for
whatever reason the `release` task is re-run and/or is out-of-order
with it's dependents, the state of cache will be undefined. Previously
this would result in an error, and failing of the release task.
This commit alters this behavior to issue a warning instead.
Signed-off-by: Chris Evich <cevich@redhat.com>
