There is weird issue #18856 which causes the version check to fail.
Return the underlying error in these cases so we can see it and debug
it.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Remove an outdated comment on the absence of exit-code propagation when
running K8s workloads in systemd. The `podman-kube@` systemd template
is using default restart policy of the system. The exit-code
propagation is tested in other tests, so we can keep the logic as is.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
One feature needed for podmansh is the ability to set the default
homedir to be the workingdir when you login.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Because of a c/storage change[1] all we get a lot of new dependencies in
rootlessport despite not using them. Add build tags to exclude storage
drivers to make the binary smaller until it get addressed in c/storage.
This saves about 800 MB but the bloat due that change is still causing
us to gain over 2 MB. This is not ideal but we should get vendoring
going and not wait any longer.
[1] https://github.com/containers/storage/pull/1618
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
add routes using the --route flag.
the no_default_route option in --opt prevents a default route from
getting added automatically.
Signed-off-by: Jan Hendrik Farr <github@jfarr.cc>
A c/storage PR[1] chnage the behavior to correctly report umount errors.
This is causing problem in the updgrade tests. The problem is that a
cotnainer is mounted inside another container and then unmounted on the
host. Therefore both operations happen in different mount namespaces.
this is expcted but we want to share the mounts between them. This is
the default but c/stroage make the root private by default thus the
mounts were not shared. To fix this use the `skip_mount_home` storage
option so the mount is kept shared.
[1] https://github.com/containers/storage/pull/1607
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In debian environment we are hitting an edge-case where older buildah
version is not compatible with newer podman version because both of them
are using different storage driver.
I.e
* Podmand defaults to native `overlay`.
* Older buildah version defaults to `vfs`.
See discussions below for more details
* containers#18510 (comment)
Co-authored-by: Ed Santiago <santiago@redhat.com>
Signed-off-by: Aditya R <arajan@redhat.com>
The Sysctl=name=value entry can be used to set --sysctl=name=value
directly without the need to use PodmanArgs=--sysctl=name=value.
Signed-off-by: Laurenz Kruty <git@laurenzkruty.de>
There are certain messages logged by OCI runtimes when killing a
container that has already stopped that we really do not care
about when stopping a container. Due to our architecture, there
are inherent races around stopping containers, and so we cannot
guarantee that *we* are the people to kill it - but that doesn't
matter because Podman only cares that the container has stopped,
not who delivered the fatal signal.
Unfortunately, the OCI runtimes don't understand this, and log
various warning messages when the `kill` command is invoked on a
container that was already dead. These cause our tests to fail,
as we now check for clean STDERR when running Podman. To work
around this, capture STDERR for the OCI runtime in a buffer only
for stopping containers, and go through and discard any of the
warnings we identified as spurious.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
On FreeBSD, it usually lives in /usr/local/bin/bash. This uses the shell
'commmand' builtin to find the path which works in bash, dash and the
FreeBSD /bin/sh.
Signed-off-by: Doug Rabson <dfr@rabson.org>
Due to a bad file-format design, if a cirrus-cron job happened to have a
name w/ spaces, the generated e-mail text would be broken. For example:
```
Cron build 'VM' Failed: https://cirrus-ci.com/build/Image Maintenance
5630822628196352
```
Fix this by flipping the field-order in an intermediate file, so the
build ID comes first, then the job name. This makes it much easier for
`read` to process, since all words will be stored into the final
variable (now the job name).
Also change all variables that reference this intermediate file such
that they continue to reflect the expected field order. Update script
tests and add a new test to confirm expected file processing and output.
Signed-off-by: Chris Evich <cevich@redhat.com>
First: fix podman-registry script so it preserves the initial $PODMAN,
so all subsequent invocations of ps, logs, and stop will use the
same binary and arguments. Until now we've handled this by requiring
that our caller manage $PODMAN (and keep it the same), but that's
just wrong.
Next, simplify the golang interface: move the $PODMAN setting into
registry.go, instead of requiring e2e callers to set it. (This
could use some work: the local/remote conditional is icky).
IMPORTANT: To prevent registry.go from using the wrong podman binary,
the Start() call is gone. Only StartWithOptions() is valid now.
And, minor cleanup: comments, and add an actual error-message check
Reason for this PR is a recurring flake, #18355, whose multiple
failure modes I truly can't understand. I don't think this PR
is going to fix it, but this is still necessary work.
Signed-off-by: Ed Santiago <santiago@redhat.com>
We use shared-memory pthread mutexes to handle mutual exclusion
in Libpod. It turns out that these have configurable options for
how to handle a recursive lock (IE, a thread trying to lock a
lock that the same thread had previously locked). The mutex can
either deadlock, or allow the duplicate lock without deadlocking.
Default behavior is, helpfully, unspecified, so if not explicitly
set there is no clear indication of which of these behaviors will
be seen. Unfortunately, today is the first I learned of this, so
our initial implementation did *not* explicitly set our preferred
behavior.
This turns out to be a major problem with a language like Golang,
where multiple goroutines can (and often do) use the same OS
thread. So we can have two goroutines trying to stop the same
container, and if the no-deadlock mutex behavior is in use, both
threads will successfully acquire the lock because the C library,
not knowing about Go's lightweight threads, sees the same PID
trying to lock a mutex twice, and allows it without question.
It appears that, at least on Fedora/RHEL/Debian libc, the default
(unspecified) behavior of the locks is the non-deadlocking
version - so, effectively, our locks have been of questionable
utility within the same Podman process for the last four years.
This is somewhat concerning.
What's even more concerning is that the Golang-native sync.Mutex
that was also in use did nothing to prevent the duplicate locking
(I don't know if I like the implications of this).
Anyways, this resolves the major issue of our locks not working
correctly by explicitly setting the correct pthread mutex
behavior.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
If the first container to get the pod lock is the infra container
it's going to want to remove the entire pod, which will also
remove every other container in the pod. Subsequent containers
will get the pod lock and try to access the pod, only to realize
it no longer exists - and that, actually, the container being
removed also no longer exists.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
This was causing some CI flakes. I'm pretty sure that the pods
being removed already isn't a bug, but just the result of another
container in the pod removing it first - so no reason not to
ignore the errors.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
This fixes a lint issue, but I'm keeping it in its own commit so
it can be reverted independently if necessary; I don't know what
side effects this may have. I don't *think* there are any
issues, but I'm not sure why it wasn't a pointer in the first
place, so there may have been a reason.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
- trust_test: adding 'Ordered' seems to resolve a very common
flake. I've tested this for dozens of CI runs, and haven't
seen the flake recur (normally it fails every few runs).
- exec and search tests: add FlakeAttempts(3). This is a NOP
under our current CI setup, in which we run ginkgo with
a global --flake-attempts=3. I am submitting this as an
optimistic step toward a no-flake-attempts world (#17967)
Fixes: #18358
Signed-off-by: Ed Santiago <santiago@redhat.com>
For filter=id=XXX (containers, pods) and =ctr-ids=XXX (pods):
if XXX is only hex characters, treat it as a PREFIX
otherwise, treat it as a REGEX
Add tests. Update documentation. And fix an incorrect help message.
Fixes: #18471
Signed-off-by: Ed Santiago <santiago@redhat.com>
