| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our previous flow was to perform a hijack before passing a
connection into Libpod, and then Libpod would attach to the
container's attach socket and begin forwarding traffic.
A problem emerges: we write the attach header as soon as the
attach complete. As soon as we write the header, the client
assumes that all is ready, and sends a Start request. This Start
may be processed *before* we successfully finish attaching,
causing us to lose output.
The solution is to handle hijacking inside Libpod. Unfortunately,
this requires a downright extensive refactor of the Attach and
HTTP Exec StartAndAttach code. I think the result is an
improvement in some places (a lot more errors will be handled
with a proper HTTP error code, before the hijack occurs) but
other parts, like the relocation of printing container logs, are
just *bad*. Still, we need this fixed now to get CI back into
good shape...
Fixes #7195
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In local Podman, the frontend interprets the error and exit code
given by the Exec API to determine the appropriate exit code to
set for Podman itself; special cases like a missing executable
receive special exit codes.
Exec for the remote API, however, has to do this inside Libpod
itself, as Libpod will be directly queried (via the Inspect API
for exec sessions) to get the exit code. This was done correctly
when the exec session started properly, but we did not properly
handle cases where the OCI runtime fails before the exec session
can properly start. Making two error returns that would otherwise
not set exit code actually do so should resolve the issue.
Fixes #6893
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| |
|
|
| |
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This was added with an earlier exec rework, and honestly is very
confusing. Podman is printing an error message, but the error had
nothing to do with Podman; it was the executable we ran inside
the container that errored, and per `podman run` convention we
should set the Podman exit code to the process's exit code and
print no error.
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was inspired by https://github.com/cri-o/cri-o/pull/3934 and
much of the logic for it is contained there. However, in brief,
a named return called "err" can cause lots of code confusion and
encourages using the wrong err variable in defer statements,
which can make them work incorrectly. Using a separate name which
is not used elsewhere makes it very clear what the defer should
be doing.
As part of this, remove a large number of named returns that were
not used anywhere. Most of them were once needed, but are no
longer necessary after previous refactors (but were accidentally
retained).
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the advent of Podman 2.0.0 we crossed the magical barrier of go
modules. While we were able to continue importing all packages inside
of the project, the project could not be vendored anymore from the
outside.
Move the go module to new major version and change all imports to
`github.com/containers/libpod/v2`. The renaming of the imports
was done via `gomove` [1].
[1] https://github.com/KSubedi/gomove
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The biggest obstacle here was cleanup - we needed a way to remove
detached exec sessions after they exited, but there's no way to
tell if an exec session will be attached or detached when it's
created, and that's when we must add the exit command that would
do the removal. The solution was adding a delay to the exit
command (5 minutes), which gives sufficient time for attached
exec sessions to retrieve the exit code of the session after it
exits, but still guarantees that they will be removed, even for
detached sessions. This requires Conmon 2.0.17, which has the new
`--exit-delay` flag.
As part of the exit command rework, we can drop the hack we were
using to clean up exec sessions (remove them as part of inspect).
This is a lot cleaner, and I'm a lot happier about it.
Otherwise, this is just plumbing - we need a bindings call for
detached exec, and that needed to be added to the tunnel mode
backend for entities.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cleanup command creation logic is made public as part of this
and wired such that we can call it both within SpecGen (to make
container exit commands) and from the ABI detached exec handler.
Exit commands are presently only used for detached exec, but
theoretically could be turned on for all exec sessions if we
wanted (I'm declining to do this because of potential overhead).
I also forgot to copy the exit command from the exec config into
the ExecOptions struct used by the OCI runtime, so it was not
being added.
There are also two significant bugfixes for exec in here. One is
for updating the status of running exec sessions - this was
always failing as I had coded it to remove the exit file *before*
reading it, instead of after (oops). The second was that removing
a running exec session would always fail because I inverted the
check to see if it was running.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to be able to use cleanup processes to remove exec
sessions as part of detached exec. This PR adds that ability. A
new flag is added to `podman container cleanup`, `--exec`, to
specify an exec session to be cleaned up.
As part of this, ensure that `ExecCleanup` can clean up exec
sessions that were running, but have since exited. This ensures
that we can come back to an exec session that was running but has
since stopped, and clean it up.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As part of the massive exec rework, I stubbed out a function for
non-detached exec, which is implemented here. It's largely
similar to the existing exec functions, but missing a few pieces.
This also involves implemented a new OCI runtime call for
detached exec. Again, very similar to the other functions, but
with a few missing pieces.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| |
|
|
|
|
|
|
|
|
|
| |
These are required for detached exec, where they will be used to
clean up and remove exec sessions when they exit.
As part of this, move all Exec related functionality for the
Conmon OCI runtime into a separate file; the existing one was
around 2000 lines.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The usual flow for exec is going to be:
- Create exec session
- Start and attach to exec session
- Exec session exits, attach session terminates
- Client does an exec inspect to pick up exit code
The safest point to remove the exec session, without doing any
database changes to track stale sessions, is to remove during the
last part of this - the single inspect after the exec session
exits.
This is definitely different from Docker (which would retain the
exec session for up to 10 minutes after it exits, where we will
immediately discard) but should be close enough to be not
noticeable in regular usage.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| |
|
|
|
|
|
| |
We can't save the exec session, but it's because the container
is entirely gone, so no point erroring.
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
If not overridden, we should use the attach configuration given
when the exec session was first created.
Also, setting streams should not conflict with a TTY - the two
are allowed together with Attach and should be allowed together
here.
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is heavily based off the existing exec implementation, but
does not presently share code with it, to try and ensure we don't
break anything.
Still to do:
- Add code sharing with existing exec implementation
- Wire in the frontend (exec HTTP endpoint)
- Move all exec-related code in oci_conmon_linux.go into a new
file
- Investigate code sharing between HTTP attach and HTTP exec.
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
|
|
|
|
| |
add the ability to attach to a running container. the tunnel side of this is not enabled yet as we have work on the endpoints and plumbing to do yet.
add the ability to exec a command in a running container. the tunnel side is also being deferred for same reason.
Signed-off-by: Brent Baude <bbaude@redhat.com>
|
| |\
| |
| | |
Implement APIv2 Exec Create and Inspect Endpoints
|
| | |
| |
| |
| |
| |
| |
| | |
Also adds some basic tests for these two. More tests are needed
but will have to wait for state to be finished.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| | |
| |
| |
| |
| |
| | |
Start and Resize require further implementation work.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We previously tried to send resize events only after the exec
session successfully started, which makes sense (we might drop an
event or two that came in before the exec session started
otherwise). However, the start function blocks, so waiting
actually means we send no resize events at all, which is
obviously worse than losing a few.. Sending resizes before attach
starts seems to work fine in my testing, so let's do that until we
get bug reports that it doesn't work.
Fixes #5584
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
|
|
|
| |
This produces detailed information about the configuration of an
exec session in a format suitable for the new HTTP API.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
|
|
As part of the rework of exec sessions, we need to address them
independently of containers. In the new API, we need to be able
to fetch them by their ID, regardless of what container they are
associated with. Unfortunately, our existing exec sessions are
tied to individual containers; there's no way to tell what
container a session belongs to and retrieve it without getting
every exec session for every container.
This adds a pointer to the container an exec session is
associated with to the database. The sessions themselves are
still stored in the container.
Exec-related APIs have been restructured to work with the new
database representation. The originally monolithic API has been
split into a number of smaller calls to allow more fine-grained
control of lifecycle. Support for legacy exec sessions has been
retained, but in a deprecated fashion; we should remove this in
a few releases.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
