You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe
Detection of the container.id via @opentelemetry/resource-detector-docker currently works by reading from /proc/self/cgroup. That does not work when cgroupv2 is turned on. However, based on these two sources there's another place to read from:
In short, the container.id could be read from /proc/self/mountinfo as well. This also works for containerd and not only docker.
Eventually it would be good to have a standard for that, but unfortunately this is a long-standing non-moving OCI issue, until then a combination of both approaches seems to be reliable enough.
Describe the solution you'd like to see
Add code that reads the container id from /proc/self/mountinfo if reading from /proc/self/cgroup failed.
Describe alternatives you've considered
As stated in the description, eventually it would be great to have this standardized, but until then this is the best way to go.
Is your feature request related to a problem? Please describe
Detection of the
container.id
via@opentelemetry/resource-detector-docker
currently works by reading from/proc/self/cgroup
. That does not work when cgroupv2 is turned on. However, based on these two sources there's another place to read from:In short, the
container.id
could be read from /proc/self/mountinfo as well. This also works forcontainerd
and not only docker.Eventually it would be good to have a standard for that, but unfortunately this is a long-standing non-moving OCI issue, until then a combination of both approaches seems to be reliable enough.
Describe the solution you'd like to see
Add code that reads the container id from
/proc/self/mountinfo
if reading from/proc/self/cgroup
failed.Describe alternatives you've considered
As stated in the description, eventually it would be great to have this standardized, but until then this is the best way to go.
cc: @abhee11, @osherv
The text was updated successfully, but these errors were encountered: