summaryrefslogtreecommitdiff
path: root/libpod/shutdown/handler.go
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>
* Fixes from make codespellDaniel J Walsh2021-04-21
| | | | Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
* Ensure shutdown handler access is syncronizedMatthew Heon2021-01-25
| | | | | | | | | | | | | | There was a potential race where two handlers could be added at the same time. Go Maps are not thread-safe, so that could do unpleasant things. Add a mutex to keep things safe. Also, swap the order or Register and Start for the handlers in Libpod runtime created. As written, there was a small gap between Start and Register where SIGTERM/SIGINT would be completely ignored, instead of stopping Podman. Swapping the two closes this gap. Signed-off-by: Matthew Heon <mheon@redhat.com>
* Do not error on installing duplicate shutdown handlerMatthew Heon2020-12-07
| | | | | | | | | | | | | | Installing a duplicate shutdown handler fails, but if a handler with the same name is already present, we should be set to go. There's no reason to print a user-facing error about it. This comes up almost nowhere because Podman never makes more than one Libpod runtime, but there is one exception (`system reset`) and the error messages, while harmless, were making people very confused (we got several bug reports that `system reset` was nonfunctional). Signed-off-by: Matthew Heon <mheon@redhat.com>
* Enforce LIFO ordering for shutdown handlersMatthew Heon2020-10-13
| | | | | | | | | | | This allows us to run both the Libpod and Server handlers at the same time without unregistering one. Also, pass the signal that killed us into the handlers, in case they want to use it to determine what to do (e.g. what exit code to set). 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>
* Add a shutdown handler packageMatthew Heon2020-10-12
We need a unified package for handling signals that shut down Libpod and Podman. We need to be able to do different things on receiving such a signal (`system service` wants to shut down the service gracefully, while most other commands just want to exit) and we need to be able to inhibit this shutdown signal while we are waiting for some critical operations (e.g. creating a container) to finish. This takes the first step by defining the package that will handle this. Signed-off-by: Matthew Heon <mheon@redhat.com>