Kill is a fast syscall, so we can reduce the sleep time from 100ms to
10ms in hope to speed things up a bit.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Commit 067442b5701f improved stopping/killing a container by detecting
whether the cleanup process has already fired and changed the state of
the container. Further improve on that by returning early instead of
trying to wait for the PID to finish. At that point we know that the
container has exited but the previous PID may have been recycled
already by the kernel.
[NO NEW TESTS NEEDED] - the absence of the two flaking tests recorded
in #17142 will tell.
Fixes: #17142
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Add a comment when SIGKILL is being used. It may help future readers
better comprehend what's going on and why.
[NO NEW TESTS NEEDED] - cannot test a comment :^)
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Move the stopSignal decl into the branch where it's actually used.
[NO NEW TESTS NEEDED] as it's just a small refactor.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
The code can be simplified by using a timer directly.
[NO NEW TESTS NEEDED] - should not change behavior.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
July 2022: test was flaking on new VM images. We needed new
images, so I filed #15014 and skipped the test.
January 2023: no attention from anyone, so I'll try bumping up
a dd timeout from 10s to 30s. But in the interim, the test
has broken: it used to expect "Containerfile" in output (this
was deliberately added in #13655)... but #16810 changed that
so Containerfile no longer appears. @flouthoc argues that
this too is deliberate (#17059). Okay, so let's change the
test then. All I care about is not adding more regressions.
Signed-off-by: Ed Santiago <santiago@redhat.com>
The latest Windows image from containers/automation_image@327d8799 auto-creates
an interactive session through winlogon autologon on boot. Additionally it
includes the PsTools psexec command on the system.
This change utilizes both aspects to launch the verification portion of the
smoke task under the interactive session, away from the session 0 execution
environment that the Cirrus agent runs in.
Since creating a new process under the interactive session requires a new token,
and by extension a clear text password, a new crypto random password is
generated to replace the ec2 boot generated one.
These changes allow WSL to once again function after its move to a store based
delivery stream (which is incompatible with session 0 execution).
Signed-off-by: Jason T. Greene <jason.greene@redhat.com>
Reserved annotations are used internally by Podman and would effect
nothing when run with Kubernetes so we should not be generating these
annotations.
Fixes: https://github.com/containers/podman/issues/17105
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
...and instrument with 'podman ps'es for debugging failures.
Test flakes pretty regularly in Fedora gating. If the increased
timeout doesn't help, at least we should be able to see if the
container is stopping or failed or something.
Signed-off-by: Ed Santiago <santiago@redhat.com>
to not give a false sense of security since these are not a security
mechanism but a hook to run arbitrary code before executing a
command.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Users need to know about this side effect.
Fixes: 5a2405ae1b3a ("Don't mount /dev/tty* inside privileged...")
Fixes: f4c81b0aa5fd ("Only prevent VTs to be mounted inside ...")
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Until Podman v4.3, privileged rootfull containers would expose all the
host devices to the container while rootless ones would exclude
`/dev/ptmx` and `/dev/tty*`.
When 5a2405ae1b3a ("Don't mount /dev/tty* inside privileged containers
running systemd") landed, rootfull containers started excluding all the
`/dev/tty*` devices when the container would be running in systemd
mode, reducing the disparity between rootless and rootfull containers
when running in this mode.
However, this commit regressed some legitimate use cases: exposing
non-virtual-terminal tty devices (modems, arduinos, serial
consoles, ...) to the container, and the regression was addressed in
f4c81b0aa5fd ("Only prevent VTs to be mounted inside privileged
systemd containers").
This now calls into question why all tty devices were historically
prevented from being shared to the rootless non-privileged containers.
A look at the podman git history reveals that the code was introduced
as part of ba430bfe5ef6 ("podman v2 remove bloat v2"), and obviously
was copy-pasted from some other code I couldn't find.
In any case, we can easily guess that this check was put for the same
reason 5a2405ae1b3a was introduced: to prevent breaking the host
environment's consoles. This also means that excluding *all* tty
devices is overbearing, and should instead be limited to just virtual
terminals like we do on the rootfull path.
This is what this commit does, thus making the rootless codepath behave
like the rootfull one when in systemd mode.
This leaves `/dev/ptmx` as the main difference between the two
codepath. Based on the blog post from the then-runC maintainer[1] and
this Red Hat bug[2], I believe that this is intentional and a needed
difference for the rootless path.
Closes: #16925
Suggested-by: Fabian Holler <mail@fholler.de>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
[1]: https://www.cyphar.com/blog/post/20160627-rootless-containers-with-runc
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=501718
The container lock is released before stopping/killing which implies
certain race conditions with, for instance, the cleanup process changing
the container state to stopped, exited or other states.
The (remaining) flakes seen in #16142 and #15367 strongly indicate a
race in between the stopping/killing a container and the cleanup
process. To fix the flake make sure to ignore invalid-state errors.
An alternative fix would be to change `KillContainer` to not return such
errors at all but commit c77691f06f61 indicates an explicit desire to
have these errors being reported in the sig proxy.
[NO NEW TESTS NEEDED] as it's a race already covered by the system
tests.
Fixes: #16142Fixes: #15367
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Every time I look at a container-removal issue I wonder why the
container isn't locked directly here, so let's add a comment here.
I am not sure whether I would be better if callers took care of
locking but for now the comment will safe the future me and probably
other readers some time.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
