Due to fsnotify/fsnotify#73 the logic in watch/inotify_tracker.go is now subject to frequent deadlocks: all you need is to try to Cleanup() a Tail object while fsnotify is trying to send a notification. With the recent fsnotify changes, Cleanup() ends up making InotifyTracker.run() call shared.removeWatch(winfo), which then calls shared.watcher.Remove(fname), which then waits until the main inotify loop is done handling the IN_IGNORED event indicating that the file is no longer being watched by the kernel. But for the inotify loop to handle this event, it needs to not be stuck on trying to send an event. Hence the deadlock if it's already in the process of trying to send an event.
Due to fsnotify/fsnotify#73 the logic in
watch/inotify_tracker.gois now subject to frequent deadlocks: all you need is to try toCleanup()aTailobject whilefsnotifyis trying to send a notification. With the recentfsnotifychanges,Cleanup()ends up makingInotifyTracker.run()callshared.removeWatch(winfo), which then callsshared.watcher.Remove(fname), which then waits until the main inotify loop is done handling theIN_IGNOREDevent indicating that the file is no longer being watched by the kernel. But for the inotify loop to handle this event, it needs to not be stuck on trying to send an event. Hence the deadlock if it's already in the process of trying to send an event.