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>
(cherry picked from commit 90ba6562d5)
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>
(cherry picked from commit 34137c40f6)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This seems to flake in the parallel CI runs as another process might
also use 8080 already.
We can use any port here so use GetPort() which should give us a
conflict free one.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 472c53b122)
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>
(cherry picked from commit 0dbe00d272)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This is really not nice but it is a quick fix to avoid more flakes.
The 10.11.12.0/24 was used by several tests and podman will only allow
the network to be created once with a given subnet so we need to ensure
they are conflict free, otherwise in parallel runs they will fail
randomly.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 97d0279e94)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The container prints "Failed to set RLIMIT_CORE: Operation not permitted"
I do not know why this fails when run with sudo but lets just skip it it
for now.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 07e257e7f6)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The test assumes a local id_ed25519 ssh key exists and is setup to
connect to its own user. That is basically never the case locally so the
test is broken by design.
If the test should run in some special CI setup where that is the case
we need to enable it and guard based on that later.
For now I just like to get the lima VM tests passing.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 1de60ebf7b)
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>
(cherry picked from commit 39ee9baf66)
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>
(cherry picked from commit 9aca6010ee)
Signed-off-by: Paul Holzinger <pholzing@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>
(cherry picked from commit 12d40777f0)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Verify that creating a secret with driver=shell and no --driver-opts
does not inherit the file driver's default path option. Before the fix,
this produced "invalid shell driver option"; after, it correctly fails
with "missing config value" for unconfigured shell commands.
Signed-off-by: Joe Doss <joe@solidadmin.com>
(cherry picked from commit 8b905613b5)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When `podman-remote` tars the context, extra `podman-build-secret*` paths were
either dropped by `.dockerignore` (#25314) or archived as absolute paths so
`COPY . .` pulled host-shaped trees into the image (#28334).
Use relative names under the primary context for extra sources and do not apply
`.dockerignore` to those forced entries.
Fixes: https://github.com/containers/podman/issues/25314
Fixes: https://github.com/containers/podman/issues/28334
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
(cherry picked from commit e18bb9ea8b)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Setting Entrypoint= (empty value) in a quadlet .container file should
produce --entrypoint "" in the generated podman command, which clears
the image's default entrypoint. Previously this was silently ignored
because lookupAndAddString skips empty values.
Move the Entrypoint key out of the generic stringKeys map and handle
it separately so that an empty value is passed through.
Closes#28213
Signed-off-by: umut-polat <52835619+umut-polat@users.noreply.github.com>
(cherry picked from commit 926f562bd5)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
If the sqlite file exists make sure we always use that db and no longer
botldb. There are known race conditions in the db migration logic that
might make it so that both database files exists at once.
In order to ensure we use the correctly migrated one we must prefer
sqlite here.
see https://github.com/containers/podman/issues/28216
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
It fails due selinux, it is unlcear why so I filled #27759 for now to
track that so we can get the image update merged.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
There are two fields I'm worried about: shared namespaces and pod
containers. Both are generated via loops over maps and are thus
non-deterministic in ordering. Throw a sort on each to fix the
order so we can actually diff `podman pod inspect` output.
Signed-off-by: Matt Heon <mheon@redhat.com>
Previously, using --secret=id=foo,env=BAR in remote mode would fail because the client sent the env var name to the server, which tried to resolve it locally. This patch modifies the client to resolve the environment variable locally, write it to a temp file, and send it as a file-based secret.
Fixes#27494
Signed-off-by: ZuhairM7 <ZuhairM7>
Signed-off-by: ZuhairM7 <zuhairmerali@gmail.com>
- Update documentation: Differentiate `unless-stopped` from `always` - containers stopped by the user before a reboot will not restart.
- Add `should-start-on-boot` filter: Identify containers that require a restart after a system reboot.
- Update command documentation: Add `restart-policy` and `label!` filters to the documentation for container commands (rm, ps, start, stop, pause, unpause, restart).
- Add `restart-policy` and `shoud-start-on-boot` to completions.
- Update service: Update `podman-restart.service` to use the `needs-restart=true` filter.
- Preserve state: Preserve the `StoppedByUser` state across reboots.
- Update API: Add a `ShouldStartOnBoot()` method to the Container API.
- Update documentation: Add descriptions for the `should-start-on-boot` filter.
Fixes: https://issues.redhat.com/browse/RHEL-129405
Fixes: https://github.com/containers/podman/issues/20418
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
<MH: Fixed cherry-pick conflicts>
Signed-off-by: Matt Heon <matthew.heon@pm.me>
- remove old CLI validation that only checked --pod flag
- add validation in namespaces.go to catch all paths (cli, quadlet, api)
- block userns mixing for all pods with infra, not just ipc/net
- update error message to be clearer
- fix test cleanup to use PodmanExitCleanly()
- use dynamic pod names in system tests to avoid conflicts
fixes#26848
Signed-off-by: 0xdvc <neilohene@gmail.com>
<MH: Fixed cherry-pick conflicts>
Signed-off-by: Matt Heon <matthew.heon@pm.me>
Fixes: #26588
For use cases like HPC, where `podman exec` is called in rapid succession, the standard exec process can become a bottleneck due to container locking and database I/O for session tracking.
This commit introduces a new `--no-session` flag to `podman exec`. When used, this flag invokes a new, lightweight backend implementation that:
- Skips container locking, reducing lock contention
- Bypasses the creation, tracking, and removal of exec sessions in the database
- Executes the command directly and retrieves the exit code without persisting session state
- Maintains consistency with regular exec for container lookup, TTY handling, and environment setup
- Shares implementation with health check execution to avoid code duplication
The implementation addresses all performance bottlenecks while preserving compatibility with existing exec functionality including --latest flag support and proper exit code handling.
Changes include:
- Add --no-session flag to cmd/podman/containers/exec.go
- Implement lightweight execution path in libpod/container_exec.go
- Ensure consistent container validation and environment setup
- Add comprehensive exit code testing including signal handling (exit 137)
- Optimize configuration to skip unnecessary exit command setup
Signed-off-by: Ryan McCann <ryan_mccann@student.uml.edu>
Signed-off-by: ryanmccann1024 <ryan_mccann@student.uml.edu>
Quadlets installed from `.quadlet` file now belongs to a single
application, anyone file removed from this application removes all the
other files as well.
Assited by: claude-4-sonnet
Signed-off-by: flouthoc <flouthoc.git@gmail.com>
Enable installing multiple quadlets from one file using '---' delimiters.
Each section requires '# FileName=<name>' comment for custom naming.
Single quadlet files remain unchanged for backward compatibility.
Assited by: claude-4-sonnet
Signed-off-by: flouthoc <flouthoc.git@gmail.com>
The remote client (podman --remote) was incorrectly throwing an error
when --detach-keys="" was specified for attach, run, or start commands.
According to documentation and the v1.7.0 release notes, specifying an
empty string should disable detaching, not cause an error.
Fixes: #27414
Signed-off-by: shiavm006 <shivammittal42006@gmail.com>
After the tests had all but passed on #27343, I noted
a minor typo. This corrects the one character flaw.
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
Error messages between runc and crun are not synchronized, and
in some case exit codes can be different, too.
Commit dd1bcabae9 ("CI: use local registry, part 2 of 3: fix tests")
removed the special case handling for runc from the
"podman run --seccomp-policy image (block all syscalls)"
test case, and so it fails, for example, like this:
Error: failed to connect to container's attach socket: /tmp/podman-e2e-2877753109/subtest-1698249469/p/root/overlay-containers/62585e98da7dc3fdb32d3b6de0980c762a8a6cde008ed35c68727fb97f5369c7/userdata/attach: no such file or directory
[FAILED] Command exited with status 127 (expected 126)
or this:
time="2025-08-29T17:16:52-07:00" level=error msg="cannot start a container that has stopped"
Error: `/usr/bin/runc start 63ce789f7037d9545cde832d29343704cab842e7288046407d0efa347d5ecb77` failed: exit status 1
[FAILED] Command exited 126 as expected, but did not emit 'OCI runtime error: runc: read from the init process'
(depending on runc version, phase of the moon etc.)
We can not reasonably expect a specific error message and exit code in
such an unusual scenario, but let's try.
With this commit, the above test passes successfully on my machine.
Tested with:
make localintegration FOCUS="block all syscalls" OCI_RUNTIME=/usr/local/bin/runc
make remoteintegration FOCUS="block all syscalls" OCI_RUNTIME=/usr/local/bin/runc
While at it, simplify the error message check for crun (we don't have to
check for the entire message, [the same] substring is fine for both
local and remote cases).
Fixes: dd1bcabae9 ("CI: use local registry, part 2 of 3: fix tests")
Reported-by: Yiqiao Pu <ypu@redhat.com>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The test for issue #19800 depended on finding a system user with an
octal UID. This approach was fragile because system users found on the
host may have a different UID in the testing image.
Use the rootless user ID instead which is likely to be octal anyway as
new user IDs start with 1000.
Signed-off-by: Ricardo Branco <rbranco@suse.de>
The test was assuming v1.41, set v1.40 explicitly for the call.
And assume that the default version is using the newer syntax.
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
All API versions before version 1.44 are now deprecated,
starting with Docker client version 1.29 giving an error:
"API version 1.41 is not supported by this client"
Previously it was backward-compatible for more than 10 years,
with version 1.24 being the version in classic Docker 1.12.
It seems like API code changes were already added?
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
<MH: Resolved cherry-pick conflict in tests>
Signed-off-by: Matt Heon <matthew.heon@pm.me>
