Detailed Description of the Problem

As seen in #1640, support for OpenTelemetry was now merged. However there are still some points which need to be addressed in order to drop the experimental status. One of them is the fact that it seems to require to create threads at runtime, which 1) requires insecure-fork-wanted which degrades security on the whole process, 2) may possibly affect the performance of the thread(s) that induce these creations by having such other threads compete with them on the same CPUs:
https://github.com/haproxy/haproxy/blob/master/addons/otel/README-configuration#L54

At the moment it's an early design limitation and it shouldn't be a problem to collect users feedback during the experimental phase. Resolving it might not be easy at all and may possibly require visible changes later (e.g. configuration etc).

Let's use this issue to enumerate the possibilities that seem worth exploring so that we can reach a stable configuration and drop the experimental status ASAP.

Expected Behavior

Have OTEL not require to disable important security protections.

Steps to Reproduce the Behavior

start haproxy with OTEL without insecure-fork-wanted ?

Do you have any idea what may have caused this?

The README explains that the OpenTelemetry C++ SDK apparently creates threads in the background for some exports and batch processing.

Do you have an idea how to solve the issue?

No particular idea since not knowing exactly how/when these threads are created, but among the possibilities that first come to mind:

• figure exactly what these threads are used for, if they are always used or only sometimes (e.g. in combination with certain features), and absolutely needed or can simply be disabled with minimal to no loss of functionality
• see if the functionality they implement cannot simply be moved to a native task, with or without upstreamable code changes in the library
• if too complicated, is this SDK the only implementation or could we switch to a better suited one at some point in time (or even create a new one) ?
• if too heavy, would there be a way to pre-create the threads at initialization time (with what CPU binding?), and flag them as unusuable for traffic processing, similar to what we do with libraries that require to access /dev/urandom and stuff like this ? This could possibly go as far as simulating an access to the lib during the init to make sure everything is created on the fly.
• if not (e.g. threads come and go), we could imagine intercepting calls to pthread_create() and clone() etc to try to adjust bindings on the fly when detecting it comes from OTEL, but that doesn't solve the security problem.
• could the tasks served by these threads run in a sidecar process communicating with haproxy (via CLI, SHM, new socketpair etc) ?

What is your configuration?

Not my config, just taken from addons/otel/README-configuration:

global
    insecure-fork-wanted

frontend otel-test-sa-frontend
      bind *:10080
      filter opentelemetry id otel-test-sa config sa/otel.cfg

Output of haproxy -vv

HAProxy version 3.4-dev8-8f06c8-150 2026/04/15 - https://haproxy.org/
Status: development branch - not safe for use in production.

Last Outputs and Backtraces

Additional Information

No response