-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix race condition leading to duplicate tailing #181
Fix race condition leading to duplicate tailing #181
Conversation
Hi @Bowbaq, great catch. About the test that is hijacking logs, would you consider instead making the |
@snorecone converted the tests. The build was still failing due to a race condition, but it's a different one. This one is because this read is not protected and the value can be written to concurrently. The last commit should fix |
@Bowbaq thanks, this is great. Sorry about the race in the test, I'll probably want to revisit the shutdown code later so that mutexes aren't used for every write. |
re: mutex I haven't benched it but my guess is, in the absence of contention, acquiring a read lock should be very cheap |
Yeah, I agree. No need to dig into it unless there's a benchmark. |
Do you know when the next release will be? We're being billed up double for our logs until we deploy this |
Sweet, thanks |
Expected
If a file is matched by two (or more) globs,
remote_syslog2
matches the first glob in the list, and ignores subsequent matchesActual
Sometimes, due to a race condition, a log file ends up being tailed twice. I encountered this today, we're using 0.18. Here's a trace. Notice that the some files are forwarded twice (line 7 and 29 for example).
Fix
Adding the file to the registry synchronously seems to fix the problem. I've added a test (not necessarily a fan of hijacking the logs but ...). Running that test on the current
master
fails most of the time.