summaryrefslogtreecommitdiff
path: root/libpod/events/logfile.go
Commit message (Collapse)AuthorAge
* podman events allow future time for --untilPaul Holzinger2020-12-11
| | | | | | | | | | | | | | | | | The podman events aren't read until the given timestamp if the timestamp is in the future. It just reads all events until now and exits afterwards. This does not make sense and does not match docker. The correct behavior is to read all events until the given time is reached. This fixes a bug where the wrong event log file path was used when running first time with a new storage location. Fixes #8694 This also fixes the events api endpoint which only exited when an error occurred. Otherwise it just hung after reading all events. Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
* add network connect|disconnect compat endpointsbaude2020-11-19
| | | | | | | | | | | this enables the ability to connect and disconnect a container from a given network. it is only for the compatibility layer. some code had to be refactored to avoid circular imports. additionally, tests are being deferred temporarily due to some incompatibility/bug in either docker-py or our stack. Signed-off-by: baude <bbaude@redhat.com>
* events endpoint: fix panic and race conditionValentin Rothberg2020-07-20
| | | | | | | | | | | | | | | | | | | | | Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25c0fca: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Another race was the handler closing event channel, which could lead to two kinds of panics: double close, send to close channel. The backend takes care of that. However, make sure that the backend stops working in case the context has been cancelled. Fixes: #6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Fix `system service` panic from early hangup in eventsMatthew Heon2020-07-02
| | | | | | | | | | | | We weren't actually halting the goroutine that sent events, so it would continue sending even when the channel closed (the most notable cause being early hangup - e.g. Control-c on a curl session). Use a context to cancel the events goroutine and stop sending events. Fixes #6805 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
* events: make sure the write channel is always closedGiuseppe Scrivano2019-11-06
| | | | | | | | | in case of errors, the channel is not closed, blocking the reader indefinitely. Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1767663 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
* add eventlogger to infobaude2019-08-02
| | | | | | | to help with future debugging, we now display the type of event logger being used inside podman info -> host. Signed-off-by: baude <bbaude@redhat.com>
* System events are valid, don't error on themMatthew Heon2019-07-31
| | | | | | The logfile driver was not aware that system events existed. Signed-off-by: Matthew Heon <matthew.heon@pm.me>
* Add System event type and renumber, refresh eventsMatthew Heon2019-04-25
| | | | | | | Also, re-add locking to file eventer Write() to protect against concurrent events. Signed-off-by: Matthew Heon <mheon@redhat.com>
* journald event loggingbaude2019-04-24
add the ability for podman to read and write events to journald instead of just a logfile. This can be controlled in libpod.conf with the `events_logger` attribute of `journald` or `file`. The default will be set to `journald`. Signed-off-by: baude <bbaude@redhat.com>