The pod name does not appear when doing `podman ps -p`.
It is missing as the documentation says:
-p, --pod Print the ID and name of the pod the containers are associated with
The pod name is added in the ps output and checked in unit tests.
Closes#4703
Signed-off-by: NevilleC <neville.cain@qonto.eu>
when removing an image from storage, we should return a struct that
details what was untagged vs deleted. this replaces the simple
println's used previously and assists in API development.
Signed-off-by: baude <bbaude@redhat.com>
When a container is in a PID namespace, it is enought to send
the stop signal to the PID 1 of the namespace, only send signals
to all processes in the container when the container is not in
a pid namespace.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
When trying to reproduce #4704 I noticed that the named volumes
from the Postgres containers in the reproducer weren't being
removed by `podman pod rm -f` saying that the container they were
attached to was still in use. This was rather odd, considering
they were only in use by one container, and that container was in
the process of being removed with the pod.
After a bit of tracing, I realized that the cause is the ordering
of container removal when we remove a pod. Normally, it's done
in removeContainer() before volume removal (which is the last
thing in that function). However, when we are removing a pod, we
remove containers all at once, after removeContainer has already
finished - meaning the container still exists when we try to
remove its volumes, and thus the volume can't be removed.
Solution: collect a list of all named volumes in use by the pod,
and remove them all at once after every container in the pod is
gone. This ensures that there are no dependency issues.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
The earlier attempt to re-add config migration only worked with
user-specified configs (podman run --config). This version works
more in line with that we want - the first rootless config file
will be changed from runc to crun.
Verified on my system after an F31 migration - everything seems
to be working well.
Signed-off-by: Matthew Heon <mheon@redhat.com>
Store the full command plus arguments of the process the container has
been created with. Expose this data as a `Config.CreateCommand` field
in the container-inspect data as well.
This information can be useful for debugging, as we can find out which
command has created the container, and, if being created via the Podman
CLI, we know exactly with which flags the container has been created
with.
The immediate motivation for this change is to use this information for
`podman-generate-systemd` to generate systemd-service files that allow
for creating new containers (in contrast to only starting existing
ones).
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Updates the podman info command to show registries from v1 config file
in the search table format.
Signed-off-by: José Guilherme Vanz <jvanz@jvanz.com>
We currently rely on exec sessions being removed from the state
by the Exec() API itself, on detecting the session stopping. This
is not a reliable method, though. The Podman frontend for exec
could be killed before the session ended, or another Podman
process could be holding the lock and prevent update (most
notable in `run --rm`, when a container with an active exec
session is stopped).
To resolve this, add a function to reap active exec sessions from
the state, and use it on cleanup (to clear sessions after the
container stops) and remove (to do the same when --rm is passed).
This is a bit more complicated than it ought to be because Kata
and company exist, and we can't guarantee the exec session has a
PID on the host, so we have to plumb this through to the OCI
runtime.
Fixes#4666
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
to make things more effecient for the api work we are doing, we should
process image filters internally (as opposed to in main). this allows
for better api responses and more closely affiliated functions.
Signed-off-by: baude <bbaude@redhat.com>
In the process, make everything in the config omitempty in TOML.
We're seeing issues (notably [1]) where, after rewriting
libpod.conf, fields that were not previously populated are
written - and, because they were not previously written, they are
included as empty. This is unfortunately different from not
included at all - it means that we need to assume the user
explicitly unset the value, and we can't use defaults. Setting
omitempty prevents us from writing things that should not be
written as they were not set originally.
[1] https://github.com/containers/libpod/issues/4210
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
When doing a checkpoint with --export the root file-system diff was not
working as expected. Instead of getting the changes from the running
container to the highest storage layer it got the changes from the
highest layer to that parent's layer. For a one layer container this
could mean that the complete root file-system is part of the checkpoint.
With this commit this changes to use the same functionality as 'podman
diff'. This actually enables to correctly diff the root file-system
including tracking deleted files.
This also removes the non-working helper functions from libpod/diff.go.
Signed-off-by: Adrian Reber <areber@redhat.com>
Return types had to change a bit for this, but since we can wrap
the old v1.ImageConfig, changes are overall not particularly bad.
At present, I believe this only works with commit, not import.
This matches how things were before we changed to the new parsing
so I think this is fine.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
It turns out we had two independent parsing impkementations for
Dockerfile instructions out of --change. My previous commit fixed
the one used in --change, but as I discovered to my dismay,
commit used a different implementation. Remove that and use the
new parsing implementation instead.
While we're at it, fix some bugs in the current commit code. The
addition of anonymous named volumes to Libpod recently means we
can now include those in the image config when committing. Some
changes (VOLUME, ENV, EXPOSE, LABEL) previously cleared the
config of the former image when used; Docker does not do this, so
I removed that behavior.
Still needs fixing: the new implementation does not support
ONBUILD, while the old one did.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
The code currently assumes that the container we delegate network
namespace to will never further delegate to another container, so
when looking up things like /etc/hosts and /etc/resolv.conf we
won't pull the correct files from the chained dependency. The
changes to resolve this are relatively simple - just need to keep
looking until we find a container without NetNsCtr set.
Fixes#4626
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
After a restart, pods and containers both run a refresh()
function to prepare to run after a reboot. Until now, volumes
have not had a similar function, because they had no per-boot
setup to perform.
Unfortunately, this was not noticed when in-memory locking was
introduced to volumes. The refresh() routine is, among other
things, responsible for ensuring that locks are reserved after a
reboot, ensuring they cannot be taken by a freshly-created
container, pod, or volume. If this reservation is not done, we
can end up with two objects using the same lock, potentially
needing to lock each other for some operations - classic recipe
for deadlocks.
Add a refresh() function to volumes to perform lock reservation
and ensure it is called as part of overall refresh().
Fixes#4605Fixes#4621
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
do not change the runtime error to be lowercase, but use a case
insensitive regex matching. In this way the original error from the
OCI runtime is reported back.
regression introduced by bc485bce47f55135d6ead80537bc145edb779ae9
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This command will destroy all data created via podman.
It will remove containers, images, volumes, pods.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Trying to checkpoint a container started with --rm works, but it makes
no sense as the container, including the checkpoint, will be deleted
after writing the checkpoint. This commit inhibits checkpointing
containers started with '--rm' unless '--export' is used. If the
checkpoint is exported it can easily be restored from the exported
checkpoint, even if '--rm' is used. To restore a container from a
checkpoint it is even necessary to manually run 'podman rm' if the
container is not started with '--rm'.
Signed-off-by: Adrian Reber <areber@redhat.com>
when parsing the OCI error, be sure to discard any other output that
is not matched. The full output is still printed with
--log-level=debug.
Closes: https://github.com/containers/libpod/issues/4574
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
We leverage the containers/storage image history tracking feature to
show the previously used image names when running:
`podman images --history`
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
These only conflict when joining more than one network. We can
still set a single CNI network and set a static IP and/or static
MAC.
Fixes#4500
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
filter option accepts two filters.
- label
- until
label supports "label=value" or "label=key=value" format
until supports all golang compatible time/duration formats.
Signed-off-by: Kunal Kushwaha <kunal.kushwaha@gmail.com>
If the container is running and we need to get its netns and
can't, that is a serious bug deserving of errors.
If it's not running, that's not really a big deal. Log an error
and continue.
Signed-off-by: Matthew Heon <mheon@redhat.com>
When Libpod removes a container, there is the possibility that
removal will not fully succeed. The most notable problems are
storage issues, where the container cannot be removed from
c/storage.
When this occurs, we were faced with a choice. We can keep the
container in the state, appearing in `podman ps` and available for
other API operations, but likely unable to do any of them as it's
been partially removed. Or we can remove it very early and clean
up after it's already gone. We have, until now, used the second
approach.
The problem that arises is intermittent problems removing
storage. We end up removing a container, failing to remove its
storage, and ending up with a container permanently stuck in
c/storage that we can't remove with the normal Podman CLI, can't
use the name of, and generally can't interact with. A notable
cause is when Podman is hit by a SIGKILL midway through removal,
which can consistently cause `podman rm` to fail to remove
storage.
We now add a new state for containers that are in the process of
being removed, ContainerStateRemoving. We set this at the
beginning of the removal process. It notifies Podman that the
container cannot be used anymore, but preserves it in the DB
until it is fully removed. This will allow Remove to be run on
these containers again, which should successfully remove storage
if it fails.
Fixes#3906
Signed-off-by: Matthew Heon <mheon@redhat.com>
When restoring a container with user namespace, the user namespace is
created by the OCI runtime, and the network namespace is created after
the user namespace to ensure correct ownership.
In this case PostConfigureNetNS will be set and the value of
c.state.NetNS would be nil. Hence, the following error occurs:
$ sudo podman run --name cr \
--uidmap 0:1000:500 \
-d docker.io/library/alpine \
/bin/sh -c 'i=0; while true; do echo $i; i=$(expr $i + 1); sleep 1; done'
$ sudo podman container checkpoint cr
$ sudo podman container restore cr
...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x13a5e3c]
Signed-off-by: Radostin Stoyanov <rstoyanov1@gmail.com>
In conmon 2.0.3, we add another fifo to handle window resizing. This needs to be cleaned up for commands like restore, where the same path is used.
Signed-off-by: Peter Hunt <pehunt@redhat.com>
Rewrite the backend for displaying the history of an image to simplify
the code and be closer to docker's behaviour. Instead of driving
index-based heuristics, create a reverse mapping from top-layers to the
corresponding image IDs and lookup the layers on-demand. Also use the
uncompressed layer size to be closer to Docker's behaviour.
Note that intermediate images from local builds are not considered for
the ID lookups anymore.
Fixes: #3359
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
