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>
On some platforms, /lib is not actually a directory, it is a symlink to
/usr/lib:
$ ls -l /lib
lrwxrwxrwx 1 root root 7 Dec 4 17:11 /lib -> usr/lib
When this is the case, "make install" will be operating under a false
assumption when it generates any relative symlinks to files under a
different root-level directory.
If linking to /libexec/... from /lib/... for example, the generated
relative symlink will be 1 parent directory pointer (../) too short.
This PR allows the builder to specify LIBDIR=/usr/lib, explicitly
installing files to the target of the symlink. This results in
symlinks being generated with the correct depth.
Signed-off-by: Jack Wearden <jack@jackwearden.co.uk>
with libhvee, we are able to do the basics of podman machine management
on hyperv. The basic functions like init, rm, stop, and start are all
functional. Start and stop will periodically throw a benign error
processing the hyperv message being returned from the action. The error
is described in the todo's below.
notable items:
* no podman commands will work (like ps, images, etc)
* the machine must be initialized with --image-path and fed a custom image.
* disk size is set to 100GB statically.
* the vm joins the default hyperv network which is TCP/IP network based.
* podman machine ssh does not work
* podman machine set does not work
* you can grab the ip address from hyperv and fake a machine connection
with `podman system connection`.
* when booting, use the hyperv console to know the boot is complete.
TODOs:
* podman machine ssh
* podman machine set
* podman machine rm needs force bool
* disk size in NewMachine is set to 100GB
* podman start needs to wait until fully booted
* establish a boot complete signal from guest
* implement gvproxy like user networking
* fix benign failures in stop/start -> Error: error 2147749890 (FormatMessage failed with: The system cannot find message text for message number 0x%1 in the message file for %2.)
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
