-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Suppress errors on EBADF when unlocking files #35706
Merged
djaglowski
merged 3 commits into
open-telemetry:main
from
sfc-gh-kstewart:filelog-receiver-fs-lock-handle-delete
Oct 9, 2024
Merged
Suppress errors on EBADF when unlocking files #35706
djaglowski
merged 3 commits into
open-telemetry:main
from
sfc-gh-kstewart:filelog-receiver-fs-lock-handle-delete
Oct 9, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…arly when delete_after_read is set and it's harmless.
bogdandrutu
approved these changes
Oct 8, 2024
djaglowski
approved these changes
Oct 8, 2024
jmichalek132
pushed a commit
to jmichalek132/opentelemetry-collector-contrib
that referenced
this pull request
Oct 10, 2024
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description This error is harmless and happens regularly when `delete_after_read` is set. This is because we acquire the lock right at the start of the `ReadToEnd` function and then defer the unlock, but that function also performs the delete. So, by the time it returns and the defer runs the file descriptor is no longer valid. <!--Describe what testing was performed and which tests were added.--> #### Testing Tested manually on a laptop running MacOS. When using `acquire_fs_locks` in conjunction with `delete_after_read` I observe this error in the logs *before applying this change*: ``` 2024-10-08T14:30:23.626-0700 error reader/reader_unix.go:28 Failed to unlock {"kind": "receiver", "name": "filelog", "data_type": "logs", "component": "fileconsumer", "path": "<redacted>", "error": "bad file descriptor"} github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/fileconsumer/internal/reader.(*Reader).unlockFile github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza@v0.111.0/fileconsumer/internal/reader/reader_unix.go:28 github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/fileconsumer/internal/reader.(*Reader).ReadToEnd github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza@v0.111.0/fileconsumer/internal/reader/reader.go:126 github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/fileconsumer.(*Manager).consume.func1 github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza@v0.111.0/fileconsumer/file.go:160 ``` Performing the same test with this changed applied eliminates the error. --------- Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>
sbylica-splunk
pushed a commit
to sbylica-splunk/opentelemetry-collector-contrib
that referenced
this pull request
Dec 17, 2024
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description This error is harmless and happens regularly when `delete_after_read` is set. This is because we acquire the lock right at the start of the `ReadToEnd` function and then defer the unlock, but that function also performs the delete. So, by the time it returns and the defer runs the file descriptor is no longer valid. <!--Describe what testing was performed and which tests were added.--> #### Testing Tested manually on a laptop running MacOS. When using `acquire_fs_locks` in conjunction with `delete_after_read` I observe this error in the logs *before applying this change*: ``` 2024-10-08T14:30:23.626-0700 error reader/reader_unix.go:28 Failed to unlock {"kind": "receiver", "name": "filelog", "data_type": "logs", "component": "fileconsumer", "path": "<redacted>", "error": "bad file descriptor"} github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/fileconsumer/internal/reader.(*Reader).unlockFile github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza@v0.111.0/fileconsumer/internal/reader/reader_unix.go:28 github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/fileconsumer/internal/reader.(*Reader).ReadToEnd github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza@v0.111.0/fileconsumer/internal/reader/reader.go:126 github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/fileconsumer.(*Manager).consume.func1 github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza@v0.111.0/fileconsumer/file.go:160 ``` Performing the same test with this changed applied eliminates the error. --------- Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This error is harmless and happens regularly when
delete_after_read
is set. This is because we acquire the lock right at the start of theReadToEnd
function and then defer the unlock, but that function also performs the delete. So, by the time it returns and the defer runs the file descriptor is no longer valid.Testing
Tested manually on a laptop running MacOS. When using
acquire_fs_locks
in conjunction withdelete_after_read
I observe this error in the logs before applying this change:Performing the same test with this changed applied eliminates the error.