Self-monitoring fails when /proc is host-mounted in a sidecar due to PID namespace mismatch

[Juandavi1]

Component(s)

No response

Is your feature request related to a problem? Please describe.

Hi!

I have a question about the self-monitoring implementation and whether the current behavior is intentional.

Would it make sense (or would it be a bad idea) for self-monitoring to resolve its own process information through /proc/self instead of relying on os.Getpid()?

Our setup is the following:

• We run the OpenTelemetry agent as a sidecar.
• The host’s /proc is bind-mounted into the container at /proc.
• This is required because the agent profiles processes running in other containers on the same node.
• For security reasons, we cannot use shareProcessNamespace.

Because of this configuration, os.Getpid() returns the PID in the container’s PID namespace, while /proc exposes the host PID namespace.

As a result, self-monitoring tries to read /proc/, but that PID does not exist in the mounted host /proc, causing a mismatch and preventing the container from starting.

Would it be reasonable for self-monitoring to obtain its own PID (or process information) from /proc/self instead? Since /proc/self resolves within the mounted proc filesystem, it would point to the correct host PID in this scenario.

I’m also interested in understanding whether this use case is considered unsupported, or if there is another recommended approach for deployments where /proc is host-mounted without sharing the PID namespace.

Thanks!

Describe the solution you'd like

Would it be possible for self-monitoring to resolve its own process information through /proc/self instead of constructing the path from os.Getpid()?

Since /proc/self is resolved by the mounted proc filesystem, it would point to the correct process in the mounted namespace, avoiding PID namespace mismatches while remaining compatible with the existing implementation.

Alternatively, if changing the default behavior is not desirable, this could potentially be an optional configuration that enables self-monitoring to use /proc/self for process discovery.

Would this approach make sense, or is there another recommended way to support deployments where /proc is host-mounted without sharing the PID namespace?

Thanks!

Describe alternatives you've considered

No response

Additional context

No response

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[iblancasa]

I think it totally makes sense.