a69a59ffc7
Fixes #27779 Currently `followLogs` can get into a deadlock if we receive an inotify IN_MODIFY event while we are trying to close the `fileWatcher`. This is due to the fact that closing the `fileWatcher` happens in the same block as consumes events from the `fileWatcher`. We are trying to run `fileWatcher.Close`, which is waiting for an IN_IGNORE event to come in over inotify to confirm the watch was been removed. But, because an IN_MODIFY event has appeared after `Close` was entered but before the IN_IGNORE, the broadcast never comes. The IN_MODIFY cannot be consumed as the events channel is unbuffered and the only `select` that reads from it is busy waiting for the IN_IGNORE event. In order to try and fix this race condition I've moved the removal of the `fileWatcher` out to a separate go block that waits for a signal to close, removes the watcher and then signals to the previous selects on the close signal. This has introduced a `fileWatcher.Remove` in the final case, but if we try and remove a watcher that does not exist it will just return an error saying so. We are not doing any checking on the return of `Remove` so this shouldn't cause any side-effects. Signed-off-by: Tom Booth <tombooth@gmail.com> |
||
|---|---|---|
| .. | ||
| jsonfilelog.go | ||
| jsonfilelog_test.go | ||
| read.go | ||