Add a new "image" mount type to `--mount`. The source of the mount is
the name or ID of an image. The destination is the path inside the
container. Image mounts further support an optional `rw,readwrite`
parameter which if set to "true" will yield the mount writable inside
the container. Note that no changes are propagated to the image mount
on the host (which in any case is read only).
Mounts are overlay mounts. To support read-only overlay mounts, vendor
a non-release version of Buildah.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
When the OCI Runtime tries to set certain settings in cgroups
it can get the error "no such file or directory", the wrapper
ends up reporting a bogus error like:
```
Request Failed(Internal Server Error): open io.max: No such file or directory: OCI runtime command not found error
{"cause":"OCI runtime command not found error","message":"open io.max: No such file or directory: OCI runtime command not found error","response":500}
```
On first reading of this, you would think the OCI Runtime (crun or runc) were not found. But the error is actually reporting
message":"open io.max: No such file or directory
Which is what we want the user to concentrate on.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
If you use additional stores and pull the same image into
writable stores, you can end up with the situation where
you have the same image twice. This causes image exists
to return the wrong error. It should return true in this
situation rather then an error.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
clean the paths before checking whether its value is different than
what is stored in the db.
Closes: https://github.com/containers/podman/issues/8160
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
We only use this channel in terminal attach, and it was not a
buffered channel originally, so it would block on trying to send
unless a receiver was ready. In the non-terminal case, there was
no receiver, so attach blocked forever. Buffer the channel for a
single bool so that it will never block, even if unused.
Fixes#8154
Signed-off-by: Matthew Heon <mheon@redhat.com>
Fix the AddMatch/SeekTail conflict. This prevents reading
unnecessary journal entries which could cause errors.
Also wrap the sdjournal errors to provide better error messages.
Fixes#8125
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
adding the ability to filter evens by the container labels. this requires that container labels be added to the events data being recorded and subsequently read.
Signed-off-by: baude <bbaude@redhat.com>
If the resolv.conf file is empty we provide default dns servers.
If the file does not exists we error and don't create the
container. We should also provide the default entries in this
case. This is also what docker does.
Fixes#8089
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
Add endpoints for the compat layer for network connect and disconnect. As of now, these two endpoints do nothing to change the network state of a container. They do some basic data verification and return the proper 200 response. This at least allows for scripts to work on the compatibility layer instead of getting 404s.
Signed-off-by: baude <bbaude@redhat.com>
This does not match Docker, which does not add hostname in this
case, but it seems harmless enough.
Fixes#8095
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Make a distinction between pods that are completely running (all
containers running) and those that have some containers going,
but not all, by introducing an intermediate state between Stopped
and Running called Degraded. A Degraded pod has at least one, but
not all, containers running; a Running pod has all containers
running.
First step to a solution for #7213.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Record the correct image name when creating a container by using the
resolved image name if present. Otherwise, default to using the first
available name or an empty string in which case the image must have been
referenced by ID.
Fixes: #8082
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
When a container either joins a pod that shares the network
namespace or uses `--net=container:` to share the network
namespace of another container, it does not have its own copy of
the CNI results used to generate `podman inspect` output. As
such, to inspect these containers, we should be going to the
container we share the namespace with for network info.
Fixes#8073
Signed-off-by: Matthew Heon <mheon@redhat.com>
When a container uses --net=host the default hostname is set to
the host's hostname. However, we were not creating any entries
in `/etc/hosts` despite having a hostname, which is incorrect.
This hostname, for Docker compat, will always be the hostname of
the host system, not the container, and will be assigned to IP
127.0.1.1 (not the standard localhost address).
Also, when `--hostname` and `--net=host` are both passed, still
use the hostname from `--hostname`, not the host's hostname (we
still use the host's hostname by default in this case if the
`--hostname` flag is not passed).
Fixes#8054
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
When an OCI runtime is given by full path, we need to ensure we
use the same runtime on subsequent use. Unfortunately, users are
often not considerate enough to use the same `--runtime` flag
every time they invoke runtime - and if the runtime was not in
containers.conf, that means we don't have it stored inn the
libpod Runtime.
Fortunately, since we have the full path, we can initialize the
OCI runtime for use at the point where we pull the container from
the database.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Say I start a container with the flag
`--runtime /usr/local/sbin/crun`. I then stop the container, and
restart it without the flag. We previously stored the runtime in
use by a container only by basename when given a path, so the
container only knows that it's using the `crun` OCI runtime - and
on being restarted without the flag, it will use the system crun,
not my special crun build.
Using the full path as the name in these cases ensures we will
still use the correct runtime, even on subsequent runs of Podman.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
The rootless-cni-infra container always has the dnsname
plugin installed. It makes no sense to check if it is
present on the host.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
Current these commands only check if a container exists in libpod. With
this fix, the commands will also check if they are in containers/storage.
This allows users to look at differences within a buildah or CRI-O container.
Currently buildah diff does not exists, so this helps out in that situation
as well as in CRI-O since the cri does not implement a diff command.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We need to do a length check before we can access the
networkStatus slice by index to prevent a runtime panic.
Fixes#8026
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
Currently the HOME environment is set to /root if
the user does not override it.
Also walk the parent directories of users homedir
to see if it is volume mounted into the container,
if yes, then set it correctly.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
After seeing #7759, I decided to look at the calls in
Podman and Buildah to see if we had issues with strings.Split()
calls where an "=" (equals) sign was in play and we expected
to split on only the first one.
There were only one or two that I found in here that I think
might have been troubling, the remainder are just adding
some extra safety.
I also had another half dozen or so that were checking length
expectations appropriately, those I left alone.
Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
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>
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>
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>
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>
It is not set based on the root image directory, and always
points at the defaults. This change will get it to follow
filepath.Join(ir.store.GraphRoot(), "cache") set from libpod.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
When we create a container, we assign a cgroup parent based on
the current cgroup manager in use. This parent is only usable
with the cgroup manager the container is created with, so if the
default cgroup manager is later changed or overridden, the
container will not be able to start.
To solve this, store the cgroup manager that created the
container in container configuration, so we can guarantee a
container with a systemd cgroup parent will always be started
with systemd cgroups.
Unfortunately, this is very difficult to test in CI, due to the
fact that we hard-code cgroup manager on all invocations of
Podman in CI.
Fixes#7830
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
