The `podman stop - basic test` flakes in CI because $SECONDS is
integer-precision: a ~14.6s stop rounds to delta_t=15 and fails
the -le 14 check. Widen the upper bound to 18s, which still catches
real regressions while tolerating slow CI nodes and remote-mode
socket overhead.
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
After _check_health "First failure" returns with FailingStreak=2, the
3rd failure fires during the subsequent systemctl checks (~1s interval),
emitting the "unhealthy" event before current_time was captured. Move
current_time before those checks so --since doesn't miss the event.
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
Test: `podman container rm --force doesn't leave running processes`
Under CI load, podman-inspect takes 2-3s per call, longer than the
2s stop-timeout window. Increase to 20s so the test reliably catches
the "stopping" state before it transitions to "exited".
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
Pause the container by default during commit. It is safer as it
avoids conflicts, and potentially security issues, when another
process is accessing the container rootfs.
Originally this was not done because it was a breaking change and
rootless containers weren't able to use the freezer cgroup controller.
Now that we support only cgroup v2, there is no gap anymore with
root (exotic configurations can still use --pause=false).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
The test flakes on the socat pid kill when the pid already exited.
Because the timeout is just 10s we can just bump it to something loinger
to ensure the process is still alive when we kill it. Also move it up a
bit so the kill happens earlier.
I observed multiple time failing with test times of 11s+. This should be
enough to make it work properly.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In the new CI with run with many parallel jobs (8) and that is messing
up timings a fair but, any command might take unexpected long to
scheduling delays and lock holding by other tests.
Any test doing a podman ps -a while need to take all container locks
for example and that then can delay the stop command an unknown amount
of time, bump the timeout to 8 and use a higher stop timeout so we are
still testing that we exit before the wait timeout is reached.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This started to fail on fedora rawhide with kernel 7.1. I have not
looked into why exactly why but the theory from commit 12d40777f0
is likely related. What I do not get is why this tests seem to pass
elsewhere, i.e. it passes in openQA and testing farm but not in our
custom lima based VMs.
Lets hope this works better.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
It is possible that the background podman stop -t 1 completes before we
get to podman kill making the kill fail as the container is not running.
The result is this error in the test:
"Error: can only kill running containers. xxx is in state exited: container state improper"
We can just bump the stop timeout to have a larger time where we can
trigger kill on a stopping container.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The problem is by default we create the systemd timers and run hc in the
background. This means any tests who depend on exact hc timing can get
broken by this so use the DISABLE_HC_SYSTEMD=true env which makes podman
skip creating the systemd timers but still allows you to manually run
the commands.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In parallel runs the timings might be a bit slower than normal. Increase
the timeout here, it should not affect the test as we use a 20s stop
timeout which is more than the ready loop which uses 5s now.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
podman ps -a causes unexpected timing delays as it tries to take locks for
all containers and parallel tests may cause it to block for a while.
In CI logs I see ps -a take over 3 seconds which is enough to mess with
the expect time and make the test fail. Since testing the ps -a output
as part of the test just switch the test to not run in parallel.
This failed with "delta t between paused and restarted" where it took 10
seconds instead of the max expected 6 seconds.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This is a long standing flake but I see it again in the lima CI, the
problem seems to happen when we stop the container before the background
healthcheck fires.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In highly parallel runs this can fail its timeout due the fact that we
run podman ps -a which takes all contianer locks, even the ones from
unrelated tests. thus this command can take a long time, from a CI log I
see:
[18:22:30.932958589] # /var/tmp/podman/bin/podman ps -a
[18:22:34.338904713] CONTAINER ID IMAGE
So like a 4s delay just on that and hence the test later failed with
"Operations took too long" as it took 7 seconds overall.
So since we know podman inspect takes the lock just keep that and not
try to get all containers for no reason.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
I saw this already in openQA and now with the new rawhide images we hit
it in upstream as well. Skip this for now to not cause so many flakes.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The test assumed /home/$USER == $HOME which may not be the case. In fact
it is not the case in the new lima VM runners.
Fix the test to actually use the path we want to test for, $HOME.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
It is not working in all ipv6 setups. In the new lima testing env
default_addr is just null causing the test to fail because the container
address was "fec0::5055:55ff:fe2b:6cc9".
For now skip this until we can figure something better out.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The pasta_t SELinux domain is denied { create } for pasta.sock
on ifconfig_var_run_t directories. Disable all pasta forwarder
tests (BATS + e2e) until a new passt release ships the fix.
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
Add rootless_port_forwarder="pasta" option that uses pesto to update
pasta's forwarding table via UNIX socket, preserving source IPs that
rootlessport's userspace proxy masks.
HostIP is stripped from port mappings in the netavark wrapper when
pasta forwarding is active because pesto handles host-side binding
while pasta's splice changes the destination IP that netavark DNAT
expects. Pesto binds both 0.0.0.0 and [::] for dual-stack support.
Fixes: https://redhat.atlassian.net/browse/RUN-2214
Fixes: https://github.com/containers/podman/issues/8193
Fixes: https://redhat.atlassian.net/browse/RUN-3587
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
This test is currently flaking with the latest pasta update[1]. As part
of debugging this it was hard to see why socat fails 5 times in this
loop as the run function does not log the output so I had to add an echo
here.
[1] https://bugs.passt.top/show_bug.cgi?id=202
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This commit addresses two concerns.
Bind dual stack when hostIP unless it is explicitly specified. Since we
use listen(), this change resulted in blocked connections on stacks
without matching DNAT rules (e.g. connecting to [::1] on an IPv4-only
network) because the TCP handshake on the reservation socket would complete
instead of returning ECONNREFUSED allowing the client to fallback to IPv4.
Replacing listen() with raw socket() and bind() syscalls fixes this by
allowing us to reserve this port without accepting connections; clients
get ECONNREFUSED and fall back to IPv4 automatically, as is desired.
Fixes: https://github.com/containers/netavark/issues/1338
Co-authored-by: Paul Holzinger <pholzing@redhat.com>
Signed-off-by: Danish Prakash <contact@danishpraka.sh>
Podman defaults to the directory of the Containerfile when no context dir is explicitly provided.
When running podman build with process subsituiton, `podman build -f <(echo "FROM scratch")`,
the Containerfile path expands to `/dev/fd/<NUM>`, which makes `/dev/fd` the context dir.
When building, Buildah attempts to create an overlay mount on top of the `/dev/fd` context dir, which fails.
In these cases, use a temp context dir instead: `$TMPDIR/podman-build-context-$randnum`
Fixes: https://github.com/containers/podman/issues/28113
Signed-off-by: Ashley Cui <acui@redhat.com>
As found in fedora openQA testing on the kernel update this test fails
due a selinux denial.
The kernel now correctly checks the backing fs selinux context in all
cases. See kernel commit 82544d36b172 (selinux: fix overlayfs mmap()
and mprotect() access checks).
The test tries to access another container so the selinux level will
be different from the quadlet roofs container and therefore fail to
access the files.
To fix this we should be able to just use the regular image mount which
has a level all containers can access. The comment that this is not
parallel safe is untrue, mounts are reference counted so this should not
get unmounted all of the sudden by another test.
In fact we have another --rootfs test case where we do this and it
passed in openQA, see "podman run - check workdir".
Fixes: #28602
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
c/common uses the new netavark create command, so some of the error messages have slightly changed. Adjust the tests so they pass.
Signed-off-by: Ashley Cui <acui@redhat.com>
When a container in a pod is stopped, its container name is removed from /etc/hosts. etchosts.Remove() filters for any entry matching the container name or the pod hostname. A pod with additional host entries like --add-host FQDN;pod-hostname:127.0.0.1 is affected by this deletion, too.
Only the container name needs to be removed when a container is stopped.
Signed-off-by: Clemens Klug <git@agp8x.org>
Use shared configfile instead of custom policy.json path handling.
This updates ocipull to rely on signature.DefaultPolicy(), removes
explicit SignaturePolicyPath, and replaces trust's custom default-policy
path logic with common configfile code.
Replace hidden `--policypath` with --signature-policy` and require
it for `trust set` command instead of path resolution based on
configfile.
For `trust get`, the `--signature-policy` is optional.
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
This was implemented by containers/netavark #1369; this commit
completes the process by wiring it into Podman. We now respect
the CLI order for configured networks - if a user passes
`--net net1,net2` we guarantee that net1 will be configured
before net2.
For containers created before this patch, we don't retain enough
information to configure networks in CLI order, so we use
alphabetical order instead to still guarantee consistency.
No breaking API changes have been made, but we do add a new
field to supplement the existing map to (optionally) provide
ordering information. The Podman CLI will always pass this.
Existing applications that do not will, again, receive]
deterministic ordering based on an alphabetical sort of network
names.
This requires the latest version of Netavark to work properly.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
The systemd timer created for health checks did not pass global
podman flags to the subprocess, causing it to use default storage
settings instead of matching the parent process. This is most
visible with --transient-store, where the healthcheck looks up
the container in the default store instead of the volatile one.
Extract GlobalPodmanArgs() from CreateExitCommandArgs so both the
exit command and healthcheck timer share the same set of global
flags (--root, --runroot, --transient-store, --storage-driver, etc.).
Fixes: https://github.com/containers/podman/issues/28483
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
PODMAN_CMD is uninitialized until basic_setup() runs, causing
podman_runtime() to invoke an empty command and fall back to [null].
Call basic_setup() before the runtime check to ensure PODMAN_CMD is
populated before use.
Signed-off-by: Ricardo Branco <rbranco@suse.de>
Adds --filter status=<value> support to podman quadlet list.
Also adds shell completion for the status filter values.
Signed-off-by: Himanshu Jaiswal <himanshu.bw5@gmail.com>
Add support for `default_host_ips` in containers.conf to set default
host IP(s) if no IP is set when forwarding ports. Multiple IPs can be
configured, and passing explicit IP with -p will always override
the configured defaults.
Signed-off-by: Danish Prakash <contact@danishpraka.sh>