-
Notifications
You must be signed in to change notification settings - Fork 40
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
Error generating reports #115
Comments
Do you have any idea how I could debug this error? Regards, |
Hi @chzgustavo Do you have pods with the same name running in different namespaces? BackgroundThe information from crio is currently queried using the hostname of the crashing container which is assumed to be unique. This container hostname is then used to match to the pod. It isn't ideal but using the hostname is the only way to try and catch the crashing container information that I am aware of. This isn't an issue in most deployment scenarios as people tend to use replicasets/deployments that generates a unique id for each pod. However if you are creating pods directly in each namespace then you may have the potential to hit a name clash issue. Possible SolutionIf that sounds like the problem I would suggest giving each pod a unique name when provisioning. |
Yes, indeed, I have many pods with the same name running in different namespaces. |
They all have the same hostname (but they are in different namespaces), is there any other possible solution for this case? |
Sorry I'm not aware of another possible solution. Statefulsets intentionally label the pods with ordinal numbers If you're using helm you can add the namespace to the statefulset name which would resolve this. The underlying issue here is that the container As systemd becomes more pod aware there may be a possibility to do something there but the last time I looked it just seemed to pass through to the system code. [Edit] [Edit2] |
…ariable from a core dump and use that as the podname If the environment variable can't be found then the composer will default back to hostname Signed-off-by: Tom Haygarth <tom@ninjakiwi.com>
Hi @No9, Thanks for the information. We continue with this bug in production since we didn't apply the "clunky workaround". Did you make some progress to fix it? This project is very useful for us, thanks for the good work. |
Hello, I am using this tool, congratulations it is very good, but I have noticed that when a segment fault is generated, it sometimes generates all the files with another namespace name.
I attach evidence.
env-1f1de3e2bda8
, when in fact this pod is in the namespace:env-e4e2facbcb22
It occurs to me to update core-dump to the newest version, I don't know if this will solve this problem.
The text was updated successfully, but these errors were encountered: