The healthcheck log could be corrupted if the
process was interrupted mid-write. It could
lead to Podman crashing.
Write the log files atomically and diferentiate
between corrupted log and different errors in
consumers of readFromFileHealthCheckLog().
Add a system test for a corrupted log file.
Change incorrect log permissions to 0o600.
Fixes: https://redhat.atlassian.net/browse/RHEL-178222
Signed-off-by: Marek Simek <msimek@redhat.com>
Add `--ignore` to `podman network rm` so removing a missing
network returns success instead of exit code 1.
Keep existing error behavior for networks in use and other failures.
This commit message was translated from Korean to English using an LLM.
Fixes: #28363
Signed-off-by: KyounghoonJang <matkimchi_@naver.com>
When parsing image envs we need to be strict about the format, only the
"key=value" format must be accepted. Just keys must be rejected as they
are not valid according to the image spec.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The exec API accepts a ConsoleSize but it is dropped: the exec
pseudo-terminal is created at its default size and only corrected
afterwards by an asynchronous resize. A short-lived exec that reads its
window size at startup (e.g. `stty size`) can therefore observe the wrong
size, because the resize may arrive after the process has already read it.
docker applies the size at creation.
Carry the requested ConsoleSize through ExecConfig and into the exec OCI
process spec (process.consoleSize) so the runtime sizes the terminal
before the process starts, removing the race. The local and remote CLIs
capture the caller's terminal size when -t is given and pass it through
ExecOptions, matching the behavior of `podman run`.
Re-enable the previously flaky `podman exec` case in the interactive
system test, which this change makes deterministic.
Signed-off-by: Shuai Yuan <shuaiyuanzju@gmail.com>
I have seen a few failures where the test fails without seeing podman rm
fail as the container was already stopped by the time we rm got called.
Bump the timeout a bit to make this less likely to happen again but not
to long as the test would take always that long otherwise.
Test log:
[15:29:08.277631195] # /var/tmp/podman/bin/podman-remote --url=unix:///tmp/bats-run-opRNXi/suite/remotesystem.podman.UvxVxO.sock run -d --name c-t108-d2t7i8rm --health-cmd /bin/false --health-interval 1s --health-retries 2 --health-timeout 1s --health-on-failure=stop --stop-timeout=2 --health-start-period 0 --stop-signal SIGTERM quay.io/libpod/testimage:20241011 sleep infinity
[15:29:09.088765794] 8946226536faa90d28dfa199e8da8fbb8040d1348a6f9142f95f3ba26f6cb2cf
[15:29:09.099141334] # /var/tmp/podman/bin/podman-remote --url=unix:///tmp/bats-run-opRNXi/suite/remotesystem.podman.UvxVxO.sock inspect --format {{.State.Pid}} c-t108-d2t7i8rm
[15:29:09.664964649] 142589
[15:29:09.678215064] # /var/tmp/podman/bin/podman-remote --url=unix:///tmp/bats-run-opRNXi/suite/remotesystem.podman.UvxVxO.sock rm c-t108-d2t7i8rm
[15:29:15.072982751] c-t108-d2t7i8rm
[15:29:15.083236575] # /var/tmp/podman/bin/podman-remote --url=unix:///tmp/bats-run-opRNXi/suite/remotesystem.podman.UvxVxO.sock container exists c-t108-d2t7i8rm
[15:29:15.193476069] [ rc=1 (expected) ]
[15:29:15.203781723] # /var/tmp/podman/bin/podman-remote --url=unix:///tmp/bats-run-opRNXi/suite/remotesystem.podman.UvxVxO.sock container exists 8946226536faa90d28dfa199e8da8fbb8040d1348a6f9142f95f3ba26f6cb2cf
[15:29:15.234141517] [ rc=1 (expected) ]
FAIL: we want at least one failure from podman-rm
expected: -gt 0
actual: 0
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Only on Fedora there's a /bin/wait shell script that calls Bash's
builtin(1). This is not the case of openSUSE Tumbleweed with the same
Bash version and Debian 13. Otherwise we get errors from bats like:
BW01: `run`'s command `wait 872594` exited with code 127, indicating
'Command not found'. Use run's return code checks, e.g. `run -127`,
to fix this message.
Replace `run wait` with `wait || true` like it's done in other tests.
Signed-off-by: Ricardo Branco <rbranco@suse.de>
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>
