Metricbeat - panic while fetching 'system/process' #5337
Assignees
Labels
Comments
|
I disabled mongodb & docker and saw it again, so it looks like it is coming from system |
andrewkroh
changed the title
|
I haven't tried to reproduce it, but I wonder if it's something with 10.12.6. In any case the gosigar code should be more defensive. |
|
Doesn't seem to happen to me, and I'm on 10.12.6. @jamiesmith Did you paste your configuration for the system module here, please? |
|
I let it run over the weekend on my laptop (10.12.6), and this didn't happen. I suspect it has something to do with the name of one of your processes. I'd say we should just make the code in gosigar more robust, even if we can't reproduce it. |
ph
added a commit
to elastic/gosigar
that referenced
this issue
Oct 10, 2017
Under some circonstance the code can fail, the root cause is not clear at the moment, but we should still make the code more robust when retrieving information for a specific process. The problem is the `bytes.SplitN` can return an array of one element making the process panic when we access the other element. This commit make the code a bit more robust and check to make sure we successfully retrieved 2 elements instead of one and return an error if it failed. Reference: elastic/beats#5337
ph
added a commit
to ph/gosigar
that referenced
this issue
Oct 10, 2017
Under some circonstance the code can fail, the root cause is not clear at the moment, but we should still make the code more robust when retrieving information for a specific process. The problem is the `bytes.SplitN` can return an array of one element making the process panic when we access the other element. This commit make the code a bit more robust and check to make sure we successfully retrieved 2 elements instead of one and return an error if it failed. Reference: elastic/beats#5337
ph
added a commit
to ph/gosigar
that referenced
this issue
Oct 10, 2017
Under some circonstance the code can fail, the root cause is not clear at the moment, but we should still make the code more robust when retrieving information for a specific process. The problem is the `bytes.SplitN` can return an array of one element making the process panic when we access the other element. This commit make the code a bit more robust and check to make sure we successfully retrieved 2 elements instead of one and return an error if it failed. Reference: elastic/beats#5337
|
I've tried to reproduce this issue on my end without luck, but I've went ahead and created a small PR on gosigar to add a safety check where the panic happened, I currently only return the PID on error, I was undecided if we should return the content of the splitted slice, or just the PID. |
|
I only saw it a couple of times- I only reported it because it said to :) Note that it also had: So not sure if the host is actually blank ( thanks! |
|
The empty value in |
ph
added a commit
to ph/gosigar
that referenced
this issue
Oct 11, 2017
Under some circonstance the code can fail, the root cause is not clear at the moment, but we should still make the code more robust when retrieving information for a specific process. The problem is the `bytes.SplitN` can return an array of one element making the process panic when we access the other element. This commit make the code a bit more robust and check to make sure we successfully retrieved 2 elements instead of one and return an error if it failed. Reference: elastic/beats#5337
ph
added a commit
to ph/gosigar
that referenced
this issue
Oct 11, 2017
Under some circonstance the code can fail, the root cause is not clear at the moment, but we should still make the code more robust when retrieving information for a specific process. The problem is the `bytes.SplitN` can return an array of one element making the process panic when we access the other element. This commit make the code a bit more robust and check to make sure we successfully retrieved 2 elements instead of one and return an error if it failed. Reference: elastic/beats#5337
ph
added a commit
to ph/gosigar
that referenced
this issue
Oct 11, 2017
Under some circonstance the code can fail, the root cause is not clear at the moment, but we should still make the code more robust when retrieving information for a specific process. The problem is the `bytes.SplitN` can return an array of one element making the process panic when we access the other element. This commit make the code a bit more robust and check to make sure we successfully retrieved 2 elements instead of one and return an error if it failed. Reference: elastic/beats#5337
andrewkroh
pushed a commit
to elastic/gosigar
that referenced
this issue
Oct 11, 2017
Under some circumstances the code can fail, the root cause is not clear at the moment, but we should still make the code more robust when retrieving information for a specific process. The problem is the `bytes.SplitN` can return an array of one element making the process panic when we access the other element. This commit make the code a bit more robust and check to make sure we successfully retrieved 2 elements instead of one and return an error if it failed. Reference: elastic/beats#5337
ph
added a commit
to ph/beats
that referenced
this issue
Oct 12, 2017
Update gosigar to make the code more robust when we cannot fetch all information for a MacOS X process. Closes: elastic#5337
andrewkroh
pushed a commit
that referenced
this issue
Oct 12, 2017
Update gosigar to make the code more robust when we cannot fetch all information for a MacOS X process. Closes: #5337
|
We are having the same problem. For the second time in 1 day. Started the daemon again so it will probably crash again soon. Using version 6.0.1 2018-01-24T08:21:06+01:00 INFO metricbeat stopped. |
|
@arkadicolson This was fixed in v6.1. Please update versions. |
|
We are running version 6.2.2 and still the same error... |
|
2018-03-26T01:54:52.640+0200 ERROR ioutil/ioutil.go:30 recovered from panic while fetching 'system/process' for host ''. Recovering, but please report this: runtime error: slice bounds out of range. |
@arkadicolson The stack trace you posted indicates this is not the same problem (your issue is with Linux, this issue is about a macOS bug). I wish I had noticed this when you first posted. Can you please open a new issue. |
|
No problem! I created ticket #6692
…On 28-03-18 17:12, Andrew Kroh wrote:
We are having the same problem.
@arkadicolson <https://github.com/arkadicolson> The stack trace you
posted indicates this is not the same problem (your issue is with
Linux, this issue is about a macOS bug). I wish I had noticed this
when you first posted. Can you please open a new issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5337 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGetSHqnKG_KYbL6bezM1ohUXPQ2-qHPks5ti6hYgaJpZM4PvT5e>.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For confirmed bugs, please report:
Saw this while monitoring on mac - docker and mongo are enabled
The text was updated successfully, but these errors were encountered: