This seems to have been added as part of the cleanup of our
handling of OOM files, but code was never added to remove it, so
we leaked a single directory with an exit file and OOM file per
container run. Apparently have been doing this for a while - I'd
guess since March of '23 - so I'm surprised more people didn't
notice.
Fixes#25291
Fixes: https://issues.redhat.com/browse/RHEL-86544, https://issues.redhat.com/browse/RHEL-86550
Signed-off-by: Matt Heon <mheon@redhat.com>
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
"podman run exit ExecErrorCodeCannotInvoke" does the same thing.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
(cherry picked from commit 35d2a65e3a)
Update cirrus.yml to the latest image based of 5.4-rhel, then disable
validate as there no point for it when we do backports. And only
perform a single build on the f41.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Since commit c25cc7230 ("Allow a value of -1 to set unlimited pids
limit") podman converts the pids-limit value of -1 to 0 for OCI spec.
Unfortunately, different runtimes (crun and runc) treat pids.limit=0
differently, and the runtime-spec definition is somewhat vague
(see [1]).
Long term fix belongs to runtime-spec and then runtimes should follow
it.
Short term fix is do not convert -1 to 0 (as all runtimes treat -1 as
unlimited).
[NO NEW TESTS NEEDED] -- this is covered by test added in commit 553e53d44.
Fixes: https://issues.redhat.com/browse/RHEL-80973
[1]: https://github.com/opencontainers/runc/issues/4014#issuecomment-1888185352
Fixes: https://issues.redhat.com/browse/RHEL-82424,
https://issues.redhat.com/browse/RHEL-82425
In the RHEL 9.6 and 10.0 ZeroDay streams
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
This resolves an ordering issue that prevented quotas from being
applied. XFS quotas are applied recursively, but only for
subdirectories created after the quota is applied; if we create
`_data` before the quota, and then use `_data` for all data in
the volume, the quota will never be used by the volume.
Also, add a test that volume quotas are working as designed using
an XFS formatted loop device in the system tests. This should
prevent any further regressions on basic quota functionality,
such as quotas being shared between volumes.
Fixes#25368
Fixes https://issues.redhat.com/browse/RHEL-82198
Fixes https://issues.redhat.com/browse/RHEL-82199
Signed-off-by: Matt Heon <mheon@redhat.com>
As discussed at the cabal October 8, 2024 we have no need for these
tests on RHEL branches.
See commit 0ed2c91 for more details.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
As part of our database init, we perform a check of the current
values for a few fields (graph driver, graph root, static dir,
and a few more) to validate that Libpod is being started with a
sane & sensible config, and the user's containers can actually be
expected to work. Basically, we take the current runtime config
and compare against values cached in the database from the first
time Podman was run.
We've had some issues with this logic before this year around
symlink resolution, but this is a new edge case. Somehow, the
database is being loaded with the empty string for some fields
(at least graph driver) which is causing comparisons to fail
because we will never compare against "" for those fields - we
insert the default value instead, assuming we have one.
Having a value of "" in the database largely invalidates the
check so arguably we could just drop it, but what BoltDB did -
and what SQLite does after this patch - is to use the default
value for comparison instead of "". This should still catch some
edge cases, and shouldn't be too harmful.
What this does not do is identify or solve the reason that we are
seeing the empty string in the database at all. From my read on
the logic, it must mean that the graph driver is explicitly set
to "" in the c/storage config at the time Podman is first run and
I'm not precisely sure how that happens.
Fixes#24738
Signed-off-by: Matt Heon <mheon@redhat.com>
For Copr builds, it will mention the Copr info from where the rpm is
installed.
For non-copr builds, it will mention the value of the packager macro
if set, and skip this field altogether if not.
On local rpm builds, this shows:
```
Build Origin: Lokesh Mandvekar <lsm5@fedoraproject.org>
```
On koji rpm builds, this shows:
```
Build Origin: Fedora Project
```
On copr rpm builds (for eg. rhcontainerbot/playground), this shows:
```
Build Origin: Copr: rhcontainerbot/playground
```
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
The default `gobuild` macro on CentOS Stream 9 now includes support for
`BUILDTAGS`.
CentOS Stream envs now also define `_user_tmpfilesdir` macro by default.
Both these definitions are no longer needed here.
`libtrust_openssl` buildtag is also set in spec wherever relevant.
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
When trying to pass a string with spaces that broke the go command cli
parsing, the full argument must be put in quotes to avoid escaping
issues.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
avoid using the glibc fork() function after using directly the clone()
syscall, as it confuses glibc causing the fork() to hang in some
cases.
The issue has been observed only on s390x, and the fix was confirmed
in the issue discussion.
Closes: https://github.com/containers/podman/issues/25184
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
BuildOrigin is a field that can be set at build time by packagers. This helps us trace how and where the binary was built and installed from, allowing us to see if the issue is due to a specfic installation or a general podman bug. This field shows up in podman version and in podman info when populated. Note that podman info has a new field, Client, that only appears when running podman info using the remote client.
Automatically set the BuildOrigin field when building the macOS pkginstaller to pkginstaller.
Usage: make podman-remote BUILD_ORIGIN="mypackaging"
Signed-off-by: Ashley Cui <acui@redhat.com>
Allowing for multiple manifest per artifact just makes the code and cli
design harder to work with it. It is not clear how mounting, extracting
or edit on a multi manifest artifact should have worked.
A single manifest should make the code much easier to work with.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Jan Rodák
openshift-merge-bot[bot]
Matt Heon
Giuseppe Scrivano
tomsweeneyredhat
Paul Holzinger
Kir Kolyshkin
Brent Baude
Lokesh Mandvekar
Lokesh Mandvekar
Ashley Cui