[Feature] Propagate trace to subprocesses via ExecIntegration

[jchamberlain]

Describe the feature you'd like

When a sub process is started via proc_open() (e.g., using Symfony's Process), environment variables must be set manually to propagate distributed tracing. Having done that, the sub process's span becomes a sibling of the sh span created by ddtrace's exec integration, but ideally it would be a child of sh.

The exec integration was updated in #3838 to propagate session ID, and the same approach could be taken to propagate the trace and parent IDs. This would solve both problems: no more manually adding env vars, and the new process could be a child of the sh span instead of a sibling.

Is your feature request related to a problem?

No response

Describe alternatives you've considered

I currently have my own hook added to proc_open() which successfully propagates the trace, but it can't access the span created in ExecIntegration.php, so I can't make the subprocess a child of sh.

Additional context

No response

[bwoebi]

Hey @jchamberlain,

This isn't quite as trivial. For proc_open injection, this works. For other mechanisms like exec(), shell_exec() etc. not quite.
We must not use putenv/setenv arbitrarily, otherwise we risk leaking memory and are unsafe in multi-threaded environments.

For session id, it's fine, because it's set only once and at process start, in a single-threaded environment.

Thus we're left with changing the command invocation for exec(), shell_exec() etc. directly (i.e. changing the string argument). This has obviously visible side effects to the command line, if anyone parses this.

I see that the span from the ExecIntegration is not accessible, that's annoying. We can at least make the switched span stack active until the end hook.

[jchamberlain]

That's a good point about exec(), etc.. (And thank you for the quick response!) Selfishly, proc_open() is all I'm after because I'm using Symfony's process pool which relies on it exclusively. And if I were to use shell_exec() or similar I wouldn't be surprised to learn that ddtrace integration with it isn't as complete. But I understand if you want to keep them consistent. Either way, yes, making that span accessible to my custom hook would be a win.