mirror of
https://github.com/moby/moby.git
synced 2022-11-09 12:21:53 -05:00
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> |
||
|---|---|---|
| .. | ||
| awslogs | ||
| etwlogs | ||
| fluentd | ||
| gcplogs | ||
| gelf | ||
| journald | ||
| jsonfilelog | ||
| logentries | ||
| loggerutils | ||
| splunk | ||
| syslog | ||
| context.go | ||
| copier.go | ||
| copier_test.go | ||
| factory.go | ||
| logger.go | ||