Add an `ExecStopPost` run even for units generated without `--new`.
Although it may seem redundant to run `container/pod stop` twice at
first glance, we really need the post run. If the main PID (i.e.,
conmon) is killed, systemd will not execute `ExecStop` but only the
post one. We made this obeservation in a customer issue and could
reproduce the behavior consistently. Hence, the post run is needed
to properly clean up when conmon is killed and it's pretty much a
NOP in all other cases.
Credits to Ulrich Obergfell for throrough and detailed analyses,
which ultimately lead to this fix.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
We initially believed that implementing this required support for
restarting containers after reboot, but this is not the case.
The unless-stopped restart policy acts identically to the always
restart policy except in cases related to reboot (which we do not
support yet), but it does not require that support for us to
implement it.
Changes themselves are quite simple, we need a new restart policy
constant, we need to remove existing checks that block creation
of containers when unless-stopped was used, and we need to update
the manpages.
Fixes#6508
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
address problem when multiple -t were sent. and rework remote build's tarball if a context dir is given other than ".".
Fixes: #6578Fixes: #6577
Signed-off-by: Brent Baude <bbaude@redhat.com>
Test has been flaking excessively. A quick look shows that
the test itself is broken, making a bad assumption.
'podman logs -f' is guaranteed to exit when a container
terminates. This does not (and should not) mean that the
container has been cleaned up. It is undefined and unsafe
to run 'podman run -n same-name-as-terminated-container'
immediately after 'podman logs' exits.
Solution: instead of 'podman run', do 'podman inspect'.
This, too, is unsafe, but we can expect to see one of
two possible conditions:
1) command succeeds, in which case we require that
container State.Status be "exited"; or
2) command fails, in which case we expect "no such
container" in error output
For full coverage we should add a small delay-check test
to (1) to ensure that the container is cleaned up after
a short amount of time. Leaving that as a TODO because
it's more than my Go skills can handle, and I want to
get this checked in ASAP to get rid of the flake hassle.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Podman is blowing up with oci-umount hook, because
it was never rewritten to support the v1.0.0 value.
This PR adds support for the older version and cleans
up the hook handling.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
These were part of Podman v1.9, but were lost in the transition
to using Specgen to create containers. Most resource limits are
checked via the sysinfo package to ensure they are safe to use
(the cgroup is mounted, kernel support is present, etc) and
removed if not safe. Further, bounds checks are performed to
ensure that values are valid.
Ensure these warnings are printed client-side when they occur.
This part is a little bit gross, as it happens in pkg/infra and
not cmd/podman, which is largely down to how we implemented
`podman run` - all the work is done in pkg/infra and it returns
only once the container has exited, and we need warnings to print
*before* the container runs. The solution here, while inelegant,
avoid the need to extensively refactor our handling of run.
Should fix blkio-limit warnings that were identified by the FCOS
test suite.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Every line is sent back individually over the APIv2 as
logs, but we are not adding the '\n' to give us line breaks.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
This started as a small fix to `podman inspect` where a container
and image, with the same name/tag, were present, and
`podman inspect` was run on that name. `podman inspect` in 1.9
(and `docker inspect`) will give you the container; in v2.0, we
gave the image. This was an easy fix (just reorder how we check
for image/container).
Unfortunately, in the process of testing this fix, I determined
that we regressed in a different area. When you run inspect on
a number of containers, some of which do not exist,
`podman inspect` should return an array of inspect results for
the objects that exist, then print a number of errors, one for
each object that could not be found. We were bailing after the
first error, and not printing output for the containers that
succeeded. (For reference, this applied to images as well). This
required a much more substantial set of changes to properly
handle - signatures for the inspect functions in ContainerEngine
and ImageEngine, plus the implementations of these interfaces,
plus the actual inspect frontend code needed to be adjusted to
use this.
Fixes#6556
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
This reverts commit 1bc992bfc3a983b4d9ab53f778a545d83bcde94d.
We originally thought `podman varlink` was entirely removed, but
that was not true. We originally thought that
`podman system service --varlink` worked the same as
`podman varlink` but that was also not true. `system service` is
broken when used under systemd units, and `podman varlink` still
exists and works. Revert the change to `podman system service` to
fix socket-activated Varlink under systemd.
Signed-off-by: Matthew Heon <mheon@redhat.com>
Fix a lint error of an used parameter. The error must have sneaked in
with a PR that was merged after the recent linter enablement.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Use the architecture of the local image when looking for a new image on
a registry. It seems to be common practice on ARM to tweak the
architecture choice to pull the correct image.
Fixes: #6613
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
