-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
filelog receiver panics when delete_after_read is true #31383
Labels
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
Removing |
djaglowski
added a commit
that referenced
this issue
Feb 26, 2024
Fixes #31383 This enhances `TestDeleteAfterRead` in a way that replicates the problem, and fixes the issue by retaining metadata on a reader until the exported `Close` function is called. Previously, we were removing the metadata when `delete` called `Close`, but this precluded the opportunity for the caller of `ReadToEnd` to properly manage file metadata after deletion.
This was referenced Feb 27, 2024
XinRanZhAWS
pushed a commit
to XinRanZhAWS/opentelemetry-collector-contrib
that referenced
this issue
Mar 13, 2024
Fixes open-telemetry#31383 This enhances `TestDeleteAfterRead` in a way that replicates the problem, and fixes the issue by retaining metadata on a reader until the exported `Close` function is called. Previously, we were removing the metadata when `delete` called `Close`, but this precluded the opportunity for the caller of `ReadToEnd` to properly manage file metadata after deletion.
ghost
pushed a commit
to opsramp/opentelemetry-collector-contrib
that referenced
this issue
May 5, 2024
Fixes open-telemetry#31383 This enhances `TestDeleteAfterRead` in a way that replicates the problem, and fixes the issue by retaining metadata on a reader until the exported `Close` function is called. Previously, we were removing the metadata when `delete` called `Close`, but this precluded the opportunity for the caller of `ReadToEnd` to properly manage file metadata after deletion.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Component(s)
receiver/filelog
What happened?
Description
When setting "delete_after_read: true" within the
filelogreceiver
, the collector panics withSteps to Reproduce
data
./otelcol --config config.yaml --feature-gates filelog.allowFileDeletion
fileconsumer/file.go:132 finding files: no files match the configured criteria
data/file.ndjson
with following contents:fileconsumer/file.go:261 Started watching file...
data/file.ndjson
as expectedExpected Result
The monitored data file is deleted, execution continues.
Actual Result
The monitored data file is deleted, a panic due to a nil pointer dereference.
This happens within Reader.ReadToEnd() as the
Reader.file
pointer is nil due to the operations ofReader.delete()
callingReader.Close()
Collector version
v0.94.0
Environment information
Environment
MacOS Sonoma 14.2.1
go version go1.21.7 darwin/amd64
OpenTelemetry Collector configuration
Log output
Additional context
I was able to fix the issue by patching Reader.ReadToEnd(ctx context.Context) with
However, I am not well versed in the otel source code and am not sure this is the correct thing to do.
The text was updated successfully, but these errors were encountered: