This hasn't been touched in 7 years and Vagarant is no longer
a default entrypoint for many people. We have other things
documented in CONTRIBUTING.
Signed-off-by: Colin Walters <walters@verbum.org>
`CRRuntimeSupportsPodCheckpointRestore()` is used to check if the current
container runtime (e.g., runc or crun) can restore a container into an
existing Pod. It does this by processing output message to check if the
`--lsm-mount-context` option is supported. This option was recently
added to crun [1], however, crun and runc have slightly different output
messages:
```
$ crun restore--lsm-mount-contextt
restore: option '--lsm-mount-context' requires an argument
Try `restore --help' or `restore --usage' for more information.
```
```
$ runc restore --lsm-mount-context
ERRO[0000] flag needs an argument: -lsm-mount-context
```
This patch updates the function to support both runtimes.
[1] https://github.com/containers/crun/pull/1578
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
Update to latest main to see if everything passes in preparation for the
first 5.3 release candidate.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
There is no good reason for the special case, kube and pod units
definitely need it. Volume and network units maybe not but for
consistency we add it there as well. This makes the docs much easier to
write and understand for users as the behavior will not differ.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
As documented in the issue there is no way to wait for system units from
the user session[1]. This causes problems for rootless quadlet units as
they might be started before the network is fully up. TWhile this was
always the case and thus was never really noticed the main thing that
trigger a bunch of errors was the switch to pasta.
Pasta requires the network to be fully up in order to correctly select
the right "template" interface based on the routes. If it cannot find a
suitable interface it just fails and we cannot start the container
understandingly leading to a lot of frustration from users.
As there is no sign of any movement on the systemd issue we work around
here by using our own user unit that check if the system session
network-online.target it ready.
Now for testing it is a bit complicated. While we do now correctly test
the root and rootless generator since commit ada75c0bb8 the resulting
Wants/After= lines differ between them and there is no logic in the
testfiles themself to say if root/rootless to match specifics. One idea
was to use `assert-key-is-rootless/root` but that seemed like more
duplication for little reason so use a regex and allow both to make it
pass always. To still have some test coverage add a check in the system
test to ask systemd if we did indeed have the right depdendencies where
we can check for exact root/rootless name match.
[1] https://github.com/systemd/systemd/issues/3312Fixes#22197
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This service is meant to be used by quadlet as replacement for
network-online.target as this does not work for rootless users.
see #22197
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The reason being that I plan to add a unit that should only be used for
the user session and otherwise there is no way to only keep a unit in
user.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Use a single loop for both the user and system service so we do not have
to duplicate the full paths every time.
In particular we can use `$^` to list all dependecies and then add the
not generated files to the loop as well to simplify this. And to make
things clear rename PODMAN_UNIT_FILES to PODMAN_GENERATED_UNIT_FILES so
readers immediately know they are generated and are safe to delete in
contrast to the .socket/.timer unit that are not and part of the git
history.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Two flakes seen in the last three months. One of them was in
August, so it's not related to ongoing criu-4.0 problems.
Suspected cause: race waiting for "podman run --rm" container
to transition from stopped to removed.
Solution: allow a 5-second grace period, retrying every second.
Also: add explanations to the Expect()s, remove unnecessary
code, and tighten up the CID check.
Signed-off-by: Ed Santiago <santiago@redhat.com>
I'm assuming this was buildah#5595: the COMMENT field moved around.
Deal with it, and add a few more checks while we're at it.
Signed-off-by: Ed Santiago <santiago@redhat.com>
...for debugging #24147, because "md5sum mismatch" is not
the best way to troubleshoot bytestream differences.
socat is run on the container, so this requires building a
new testimage (20241011). Bump to new CI VMs[1] which include it.
[1] https://github.com/containers/automation_images/pull/389
Signed-off-by: Ed Santiago <santiago@redhat.com>
The current mypod hack breaks down when running individual tests:
$ hack/bats 010 <<< barfs because it does not want pause-image!
Reason: Bats does not provide any official way to tell if tests
are being run in parallel.
Workaround: use an undocumented way.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Fixes#24267
This commit replaces a potentially unsafe slice-assignment with a call to `slices.Clone`.
This could prevent a bug where `saveCommand` and `loadCommand` could end up sharing an underlying array if `parentFlags` has a cap > it's len.
Signed-off-by: Zachary Hanham <z.hanham00@gmail.com>
The special handling to return the exit code after the container has
been removed should only be done if there are no special conditions
requested. If a user asked for running or nay other state returning the
exit code immediately with a success response is just wrong. We only
want to allow that so the remote client can fetch the exit code without
races.
Fixes b3829a2932 ("libpod API: make wait endpoint better against rm races")
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Accidentally introduced in #21639.
Thanks to Paul for the Python code to prevent this from
happening again.
Signed-off-by: Ed Santiago <santiago@redhat.com>
The doc has been reorganized and reordered. New sections have
been added as necessary to cover things not covered by the old
guide. Some sections were expanded (e.g. detailing differences
between E2E and System tests). Some sections that we did not
actually follow were removed.
Fixes https://issues.redhat.com/browse/RUN-2281
Signed-off-by: Matt Heon <mheon@redhat.com>
The close is replaced in the body of the error condition.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Tigran Sogomonian <tsogomonian@astralinux.ru>
By default golang programs exit 2 on special exit signals that can be
cought and produce a stack trace. However this is behavior that can be
modfied via GOTRACEBACK=crash[1], in that case it does not exit(2) but
rather sends itself SIGABRT to the parent sees the signal exit and out
test sees that es exit code 134, 128 + 6 (SIGABRT), like most shells do.
As it turns out GOTRACEBACK=crash is the default mode on all fedora and
RHEL rpm builds as they patch the build with a special
"rpm_crashtraceback" go build tag.
While that change is old and existing for a very long time it was never
caught until commit 5e240ab1f5, which switched the old ExitWithError()
check that accepted anything > 0, to just accept 2. And as CI only test
upstream builds that are build without rpm_crashtraceback we did not
catch in CI either. Only once a user actually used distro build against
the source e2e test it failed.
I like to highlight that running distro builds against upstream e2e
tests is not something we really support or plan to support but given
this is a easy fix I decided to just fix it here as any user with
GOTRACEBACK=crash set would face the same issue.
While I touch this test remove the unnecessary RestoreArtifact() call
which is not needed at all as we do nothing with the image and just
slows the test down for now reason.
[1] https://pkg.go.dev/runtime#section-sourcefilesFixes#24213
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
