summaryrefslogtreecommitdiff
path: root/pkg/domain/infra/abi/terminal
Commit message (Collapse)AuthorAge
* make sure that signal buffers are sufficiently bigValentin Rothberg2021-08-17
| | | | | | | | | | | | | | | Dealing with os.Signal channels seems more like an art than science since signals may get lost. os.Notify doesn't block on an unbuffered channel, so users are expected to know what they're doing or hope for the best. In the recent past, I've seen a number of flakes and BZs on non-amd64 architectures where I was under the impression that signals may got lost, for instance, during stop and exec. [NO TESTS NEEDED] since this is art. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Fix resize race with podman exec -itPaul Holzinger2021-06-16
| | | | | | | | | | | When starting a process with `podman exec -it` the terminal is resized after the process is started. To fix this allow exec start to accept the terminal height and width as parameter and let it resize right before the process is started. Fixes #10560 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
* Add --requires flag to podman run/createMatthew Heon2021-04-06
| | | | | | | | | | | | | | | | | | | | Podman has, for a long time, had an internal concept of dependency management, used mainly to ensure that pod infra containers are started before any other container in the pod. We also have the ability to recursively start these dependencies, which we use to ensure that `podman start` on a container in a pod will not fail because the infra container is stopped. We have not, however, exposed these via the command line until now. Add a `--requires` flag to `podman run` and `podman create` to allow users to manually specify dependency containers. These containers must be running before the container will start. Also, make recursive starting with `podman start` default so we can start these containers and their dependencies easily. Fixes #9250 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
* prune remotecommand dependencybaude2021-02-25
| | | | | | | | | | | prune a dependency that was only being used for a simple struct. Should correct checksum issue on tarballs [NO TESTS NEEDED] Fixes: #9355 Signed-off-by: baude <bbaude@redhat.com>
* bump go module to v3Valentin Rothberg2021-02-22
| | | | | | | | | We missed bumping the go module, so let's do it now :) * Automated go code with github.com/sirkon/go-imports-rename * Manually via `vgrep podman/v2` the rest Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* When container stops, drop sig-proxy errors to infosMatthew Heon2020-10-30
| | | | | | | | | | | | | | The sig-proxy code is set up to error on failing to forward signals to a container. This is reasonable in cases where the container is running, but something strange went wrong - but when the Kill fails because the container is stopped, we shouldn't bother with aggressive Error logging since this is an expected part of the container lifecycle - it stops, and then `podman run` also stops, but there is a timing window in between where signals will fail to be proxied, and we should not print angry errors during that. Signed-off-by: Matthew Heon <mheon@redhat.com>
* Enable masking stop signals within container creationMatthew Heon2020-10-12
| | | | | | | | | | | | | | | | | Expand the use of the Shutdown package such that we now use it to handle signals any time we run Libpod. From there, add code to container creation to use the Inhibit function to prevent a shutdown from occuring during the critical parts of container creation. We also need to turn off signal handling when --sig-proxy is invoked - we don't want to catch the signals ourselves then, but instead to forward them into the container via the existing sig-proxy handler. Fixes #7941 Signed-off-by: Matthew Heon <mheon@redhat.com>
* update github.com/docker/docker and relevant depsAkihiro Suda2020-09-18
| | | | Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
* Switch all references to github.com/containers/libpod -> podmanDaniel J Walsh2020-07-28
| | | | Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
* move go module to v2Valentin Rothberg2020-07-06
| | | | | | | | | | | | | | | 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>
* Add CLI frontend for detached execMatthew Heon2020-05-20
| | | | | | | | | | | Add a new ContainerEngine method for creating a detached exec session, and wire in the frontend code to do this. As part of this, move Streams out of ExecOptions to the function signature in an effort to share the struct between both methods. Fixes #5884 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
* podman rmi: refactor logicValentin Rothberg2020-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | While this commit was initially meant to fix #5847, it has turned into a bigger refactoring which I did not manage to break into smaller pieces: * Fix #5847 by refactoring the image-removal logic. * Make the api handler for image-removal use the ABI code. This way, both (i.e., ABI and Tunnel) end up using the same code. Achieving this code share required to move some code around to prevent circular dependencies. * Everything in pkg/api (excluding pkg/api/types) must now only be accessed from code using `ABISupport`. * Avoid imports from entities on handlers to prevent circular dependencies. * Move `podman system service` logic into `cmd` to prevent circular dependencies - it depends on pkg/api. * Also remove the build header from infra/abi files. It will otherwise confuse swagger and other tools; errors we cannot fix as go doesn't expose a build-tag env variable. Fixes: #5847 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* v2podman attach and execBrent Baude2020-04-05
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>