When run with --cgroups=split mode (e.g. quadlet) we do not use the a
separate cgroup for the container and just run in the unit cgroup.
When we filter logs we thus must match the unit name.
Added a small test to the quadlet test to make sure it will work.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
It makes little sense to create a log line string from the entry just to
parse it again into a LogLine. We have the typed fields so we can
assemble the logLine direclty, this makes things simpler and more
efficient.
Also entries from the passthrough driver do not use the CONTAINER_ID_FULL
field, instead we can just access c.ID() directly.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The passthrough driver is designed for use in systemd units. By default
we can expect systemd to log the output on journald unless the unit sets
differen StandardOutput/StandardError settings.
At the moment podman logs just errors out when the passthrough driver is
used. With this change we will read the journald for the unit messages.
The logic is actually very similar to the existing one, we just need to
change the filter. We now filter by SYSTEMD_UNIT wich equals to the
contianer cgroup, this allows us the actually filter on a per contianer
basis even when multiple contianers are started in the same unit, i.e.
via podman-kube@.service.
The only difference a user will see is that journald will merge
stdout/err into one stream so we loose the separation there.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This was added as hack in commit 6b06e9b77c because the journald logs
code was not able to handle an empty journal. But since commit
767947ab88 this is no longer the case, we correctly use the sd_journal
API and know when the journal is empty.
Therefore we no longer need this hack and it should be removed because
it just adds overhead and an empty journal entry for no good reason.
[NO NEW TESTS NEEDED]
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
* Utils must support higher level API to create Tar with chrooted into
directory
* Volume export: use TarwithChroot instead of Tar so we can make sure no
symlink can be exported by tar if it exists outside of the source
directory.
* container export: use chroot and Tar instead of Tar so we can make sure no
symlink can be exported by tar if it exists outside of the mointPoint.
[NO NEW TESTS NEEDED]
[NO TESTS NEEDED]
Race needs combination of external/in-container mechanism which is hard to repro in CI.
Closes: BZ:#2168256
CVE: https://access.redhat.com/security/cve/CVE-2023-0778
Signed-off-by: Aditya R <arajan@redhat.com>
we were previously using an experimental feature in crun, but we lost
this capability once we moved to using the OCI runtime spec to specify
the volume mappings in fdcc2257df.
Add the same feature to libpod, so that we can support relative
positions for the idmaps.
Closes: https://github.com/containers/podman/issues/17517
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
When generating a kube yaml with kube generate, do not
set the hostPort in the pod spec if the service flag is
set and we are generating a service kind too.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
* add tests
* add documentation for --shm-size-systemd
* add support for both pod and standalone run
Signed-off-by: danishprakash <danish.prakash@suse.com>
Add a podman ulimit annotation to kube generate and play.
If a container has a container with ulimits set, kube gen
will add those as an annotation to the generated yaml.
If kube play encounters the ulimit annotation, it will set
ulimits for the container being played.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
The tests for generating username/passwd entries assume that
UID/GID 123/456 do not exist, which is not a safe assumption on
Debian. If a /etc/passwd entry with that UID/GID already exists,
the test will not add a new one with the same UID/GID, and will
fail. Change UID and GID to be 6 digits, because we're a lot less
likely to collide with UIDs and GIDs in use on the system that
way. Could also go further and randomly generate the UID/GID, but
that feels like overkill.
Fixes#17366
Signed-off-by: Matt Heon <mheon@redhat.com>
The new version contains the ginkgolinter, which makes sure the
assertions are more helpful.
Also replace the deprecated os.SEEK_END with io.SeekEnd.
There is also a new `musttag` linter which checks if struct that are
un/marshalled all have json tags. This results in many warnings so I
disabled the check for now. We can reenable it if we think it is worth
it but for now it way to much work to fix all report problems.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Do not save the container each for changing the state and for removing
running exec sessions. Saving the container is expensive and avoiding
the redundant save makes `container rm` 1.2 times faster on my
workstation.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
In the super rare case that there are two containers with the same ID
for two different users, podman logs with the journald driver would show
logs from both containers.
[NO NEW TESTS NEEDED] Impossible to reproduce.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
I noticed this while running some things in parallel, podman events
would show events from other users. Because all events are written to
the journal everybody can see them. So when we read the journal we must
filter events for only the current UID.
To reproduce run `podman events` as user then in another window create a
container as root for example. After this patch it will correctly ignore
these events from other users.
[NO NEW TESTS NEEDED] I don't think we can test with two users at the same
time.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Loading container states speed things up when listing all containers but
it comes with a price tag for many other call paths. Hence, make
loading the state conditional to allow for keeping `podman ps` fast
without other commands regressing in performance.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Do not sync containers with the runtime and the database when listing
containers. It turns out to be extremely expensive and unnecessary.
The sync was needed since listing all containers from the database did
not populate their state. Doing that, however, is much faster since we
already have a connection to the database.
This change makes listing 200 containers 2 times faster than before.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
If the image being used has a user set that is a positive
integer greater than 0, then set the securityContext.runAsNonRoot
to true for the container in the generated kube yaml.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
Also do not return (and immediately suppress) an error if no health
check is defined for a given container.
Makes listing 100 containers around 10 percent faster.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
After https://github.com/containers/netavark/pull/452 `netavark` is
incharge of deciding `custom_dns_servers` if any so lets honor that and
libpod should not set these manually.
This also ensures docker parity
Podman populates container's `/etc/resolv.conf` with custom DNS servers ( specified via `--dns` or `dns_server` in containers.conf )
even when container is connected to a network where `dns_enabled` is `true`.
Current behavior does not matches with docker, hence following commit ensures that podman only populates custom DNS server when container is not connected to any network where DNS is enabled and for the cases where `dns_enabled` is `true`
the resolution for custom DNS server will happen via ( `aardvark-dns` or `dnsname` ).
Reference: https://docs.docker.com/config/containers/container-networking/#dns-services
Closes: containers#16172
Signed-off-by: Aditya R <arajan@redhat.com>
Aardvark-dns and netavark now accepts custom DNS servers for containers
via new config field `dns_servers`. New field allows containers to use
custom resolvers instead of host's default resolvers.
Following commit instruments libpod to pass these custom DNS servers set
via `--dns` or central config to the network stack.
Depends-on:
* Common: containers/common#1189
* Netavark: containers/netavark#452
* Aardvark-dns: containers/aardvark-dns#240
Signed-off-by: Aditya R <arajan@redhat.com>
Kill is a fast syscall, so we can reduce the sleep time from 100ms to
10ms in hope to speed things up a bit.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Commit 067442b570 improved stopping/killing a container by detecting
whether the cleanup process has already fired and changed the state of
the container. Further improve on that by returning early instead of
trying to wait for the PID to finish. At that point we know that the
container has exited but the previous PID may have been recycled
already by the kernel.
[NO NEW TESTS NEEDED] - the absence of the two flaking tests recorded
in #17142 will tell.
Fixes: #17142
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Add a comment when SIGKILL is being used. It may help future readers
better comprehend what's going on and why.
[NO NEW TESTS NEEDED] - cannot test a comment :^)
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Move the stopSignal decl into the branch where it's actually used.
[NO NEW TESTS NEEDED] as it's just a small refactor.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
The code can be simplified by using a timer directly.
[NO NEW TESTS NEEDED] - should not change behavior.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Reserved annotations are used internally by Podman and would effect
nothing when run with Kubernetes so we should not be generating these
annotations.
Fixes: https://github.com/containers/podman/issues/17105
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The container lock is released before stopping/killing which implies
certain race conditions with, for instance, the cleanup process changing
the container state to stopped, exited or other states.
The (remaining) flakes seen in #16142 and #15367 strongly indicate a
race in between the stopping/killing a container and the cleanup
process. To fix the flake make sure to ignore invalid-state errors.
An alternative fix would be to change `KillContainer` to not return such
errors at all but commit c77691f06f indicates an explicit desire to
have these errors being reported in the sig proxy.
[NO NEW TESTS NEEDED] as it's a race already covered by the system
tests.
Fixes: #16142Fixes: #15367
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Every time I look at a container-removal issue I wonder why the
container isn't locked directly here, so let's add a comment here.
I am not sure whether I would be better if callers took care of
locking but for now the comment will safe the future me and probably
other readers some time.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
This is a cleaner solution and guarantees the variables
will be used before they are initialized.
[NO NEW TESTS NEEDED]
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
OpenShift Merge Robot
dependabot[bot]
Paul Holzinger
Aditya R
Giuseppe Scrivano
Urvashi Mohnani
danishprakash
Erik Sjölund
Daniel J Walsh
Matt Heon
Valentin Rothberg