...not CONTAINERS_CONF. At least for most tests.
Nearly every system test currently using CONTAINERS_CONF=tmpfile
should be using CONTAINERS_CONF_OVERRIDE.
Simple reason: runtime (crun/runc), database_backend (bolt/sqlite),
logger, and other important settings from /etc/c.conf are not
usually written into the tmpfile. Those tests, therefore, are
not running podman as configured on the system.
Much more discussion: #15413
This PR is a prerequisite for enabling sqlite system tests. For
the sake of simplicity and sanity, I choose to submit the sqlite
switch as a separate PR once this passes and merges.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Race introduced in #16709, which changed 'top' to 'true', so
there was only a narrow window in which '.State.ConmonPod'
would be valid. Remove the race.
Fixes: #17882
Signed-off-by: Ed Santiago <santiago@redhat.com>
when looking for a machine, look it up locally first to prevent
accidental collision with non-podman machine vms. in the cast of
`podman machine ls`, only list podman machines found by json files
Enabled remove with force.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
The os.IsNotExist() function comment mentions that new code should use
`errors.Is(err, fs.ErrNotExist)` instead.
The check was already in CI but used the wrong function name (extra s.)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
If a container with an ID starting with "db1" exists, and a
container named "db1" also exists, and they are different
containers - if I run `podman inspect db1` the container named
"db1" should be inspected, and there should not be an error that
multiple containers matched the name or id "db1". This was
already handled by BoltDB, and now is properly managed by SQLite.
Fixes#17905
Signed-off-by: Matt Heon <mheon@redhat.com>
Make sure we can install podman even when the podman-mac-helper install
command fails. This used to be the behavior but commit bae07b6ea2 caused
the regression because the binary now returns 1 as exit code on errors.
[NO NEW TESTS NEEDED] I am not sure if we can test the install step in
CI.
Fixes#17910
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Since commit bae07b6ea2 we exit with 1 one errors. This caused problem
for the mac installer which fails because of the error now.
If the helper is already installed do not treat this as hard error and
just log it instead.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The DB config is a single-row table, and the first Podman process
to run against the database creates it. However, there was a race
where multiple Podman processes, started simultaneously, could
try and write it. Only the first would succeed, with subsequent
processes failing once (and then running correctly once re-ran),
but it was happening often in CI and deserves fixing.
[NO NEW TESTS NEEDED] It's a CI flake fix.
Signed-off-by: Matt Heon <mheon@redhat.com>
Add yet another environment variable for loading containers.conf.
When CONTAINERS_CONF_OVERRIDE is set, the specified config file
will be loaded last - even when CONTAINERS_CONF is set.
This mechanism is needed to preserve system settings and other
environment variables. Setting CONTAINERS_CONF will load only
the specified config file and ignore all system and user paths.
That makes testing hard as many Podman tests use CONTAINERS_CONF
for testing.
The intended use of CONTAINERS_CONF_OVERRIDE is to set it during tests
and point it to a specific configuration of Podman (e.g., netavark with
sqlite backend).
Similar needs have popped up talking to users in the automotive and
high-performance computing space. In a way, such a setting allows for
specifying a specific "flavor" of Podman while preserving all existing
settings on the system.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
SQLite developers consider it a misfeature [1], and after turning it on,
we saw a new set of flakes. Let's turn it off and trust the developers
[1] that WAL mode is sufficient for our purposes.
Turning the shared cache off also makes the DB smaller and faster.
[NO NEW TESTS NEEDED]
[1] https://sqlite.org/forum/forumpost/1f291cdca4
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
We use the same endpoint for libpod and docker compat API. However as
reported docker returns "id" lowercase. Because we cannot break the
libpod API right now keep the output for the libpod endpoint and only
change the docker one.
To do so simply use two types that we can cast with different JSON tags.
Fixes#17869
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The symptoms in #17859 indicate that setting the PRAGMAs in individual
EXECs outside of a transaction can lead to concurrency issues and
failures when the DB is locked. Hence set all PRAGMAs when opening
the connection. Move them into individual constants to improve
documentation and readability.
Further make transactions exclusive as #17859 also mentions an error
that the DB is locked during a transaction.
[NO NEW TESTS NEEDED] - existing tests cover the code.
Fixes: #17859
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
<MH: Cherry-picked on top of my branch>
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
I was searching the SQLite docs for a fix, but apparently that
was the wrong place; it's a common enough error with the Go
frontend for SQLite that the fix is prominently listed in the API
docs for go-sqlite3. Setting cache mode to 'shared' and using a
maximum of 1 simultaneous open connection should fix.
Performance implications of this are unclear, but cache=shared
sounds like it will be a benefit, not a curse.
[NO NEW TESTS NEEDED] This fixes a flake with concurrent DB
access.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
skip in setup() if journald unavailable.
To be pedantic, this is overkill: some quadlet tests pass
because they don't run journald. Too bad.
Also skip a play-kube test that requires journal
Signed-off-by: Ed Santiago <santiago@redhat.com>
...and add a comment explaining why. The minimum, determined via
binary search, is actually 27! Anything under that will barf:
$ bin/podman run --ulimit nofile=26:26 --rm quay.io/libpod/testimage:20221018 true
Error: OCI runtime error: crun: openat2 `proc/sysrq-trigger`: Too many open files
Play it safe, go with 30.
(Does this seem alarming to anyone else, or am I the only one??)
Fixes: #17860
Signed-off-by: Ed Santiago <santiago@redhat.com>
* There's a new --db-backend option. Hide it, and actually
just assume that any new --foo-backend option will
have an arg that needs to be hidden.
* Friendly-ize "Running: quadlet ..." because those messages
include a "with QUADLET_FOO=bar" string that looks like
it's part of the command line but is not, and it's really
hard for a human eye to see what's command line and what's
extra comment.
Add tests.
Signed-off-by: Ed Santiago <santiago@redhat.com>
If the volume source starts with . resolve the path relative to the
location of the unit file
Update the test code to allow verification of regex for the value in key
value arguments
Add the usage of relative paths to the volume and mount test cases
Update the man page
Signed-off-by: Ygal Blum <ygal.blum@gmail.com>
Since we can't guarantee when the worker queue will come
and clean up the service container in the remote case when
podman kube play --wait is called, cleanup the service container
at the end of PlayKubeDown() to ensure that it is removed right
after all the containers, pods, volumes, etc are removed.
[NO NEW TESTS NEEDED]
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
As described in #17777, the `restart` on-failure action did not behave
correctly when the health check is being run by a transient systemd
unit. It ran just fine when being executed outside such a unit, for
instance, manually or, as done in the system tests, in a scripted
fashion.
There were two issue causing the `restart` on-failure action to
misbehave:
1) The transient systemd units used the default `KillMode=cgroup` which
will nuke all processes in the specific cgroup including the recently
restarted container/conmon once the main `podman healthcheck run`
process exits.
2) Podman attempted to remove the transient systemd unit and timer
during restart. That is perfectly fine when manually restarting the
container but not when the restart itself is being executed inside
such a transient unit. Ultimately, Podman tried to shoot itself in
the foot.
Fix both issues by moving the restart logic in the cleanup process.
Instead of restarting the container, the `healthcheck run` will just
stop the container and the cleanup process will restart the container
once it has turned unhealthy.
Fixes: #17777
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
