events endpoint: fix panic and race condition

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>

1 files changed, 8 insertions, 0 deletions

diff --git a/libpod/events/logfile.go b/libpod/events/logfile.go
index 28d0dc07e..b70102450 100644
--- a/libpod/events/logfile.go
+++ b/libpod/events/logfile.go
@@ -63,6 +63,14 @@ func (e EventLogFile) Read(ctx context.Context, options ReadOptions) error {
 		}
 	}()
 	for line := range t.Lines {
+		select {
+		case <-ctx.Done():
+			// the consumer has cancelled
+			return nil
+		default:
+			// fallthrough
+		}
+
 		event, err := newEventFromJSONString(line.Text)
 		if err != nil {
 			return err