Introduce process.launch_path to replace process.executable.path

[thompson-tomo]

Changes

This provides a solution to the recent discussion about the process.executable use case of where it is possible for multiple copies of the one executable residing on the one system.

The reason why the new attribute resides on the process entity is because a single process executable can be located at multiple different paths hence the difficulty in keeping it on the existing entity see https://cloud-native.slack.com/archives/C06QEG97W7L/p1776775889053099 which is connected to #3536 (comment)

Also by naming it launch_path we can better cater for scenarios where the executable is running a script and that is the source of the telemetry.

Important

Pull requests acceptance are subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above, may be automatically rejected and closed.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[braydonk]

I can't find within this PR any indication of how one is expected to instrument this. I can't think of any robust way to actually consistently retrieve this information from an OS process. In the example provided, you could get that information by parsing /proc/<pid>/cmdline, but that just happens to work in the happy path, that's not sufficient for us to introduce an attribute for.

[thompson-tomo]

In effect we need a way to know if the exe returned via pid is in fact the runtime. If it is a runtime then we need to switch to extracting from cmdline.

This is needed as otherwise the build_id & name of process.executable will be referring to different things with name being the same as process.runtime.

[braydonk]

I don't think this needs to be deprecated. The attribute itself is fine. It being identifying on the executable entity was my only problem.

[thompson-tomo]

The issue is it needs to come off the entity as the entity is not describing an instance of the executable file but rather the executable itself regardless of where it is. This leaves no usage of the attribute.

[florianl]

From a Profiling perspective this is a hard breaking change that will cause issues around symbolization.
Instead of replacing process.executable.path with process.entrypoint, process.entrypoint should be a complementary attribute and independent from process.executable.path.

E.g. in a process that uses pytorch to do something, there will be multiple process.executable.path from a Profiling perspective. One for /usr/bin/python (or any other path to a python runtime executable), one for something like libtorch and maybe something device/GPU specific.

[thompson-tomo]

Instead of replacing process.executable.path with process.entrypoint, process.entrypoint should be a complementary attribute and independent from process.executable.path.

I agree the entity needs to be seperated, however without renaming it leads to confusion as the definition of the namespace & entity differ in what they correspond to.

E.g. in a process that uses pytorch to do something, there will be multiple process.executable.path from a Profiling perspective. One for /usr/bin/python (or any other path to a python runtime executable), one for something like libtorch and maybe something device/GPU specific.

The information I was given was that path is only used as a resource attribute hence we could only have 1 attribute value.

The issue raised from system sig was how do we handle renaming/moving the executable hence why path can not be identifying.

Isn't htlhash sufficient to perform symbolisation hence why it is on the mapping message?

I also note the attributes are not mentioned in the published profiling spec.

[florianl]

I view the process.executable.* namespace, which encompasses build_id.gnu, build_id.go, build_id.htlhash, name, and path, as a cohesive unit. Collectively, these attributes serve to uniquely identify an element.

Redirecting the process.executable.build_id.* sub-namespace to process.entrypoint for executable identification does not seem appropriate. Consequently, I consider process.entrypoint to be a complementary addition rather than a replacement for process.executable.path.

[florianl]

A script can never be an executable. The shebang at the beginning of a script defined the executable.

Suggested change

	| <a id="process-entrypoint" href="#process-entrypoint">`process.entrypoint`</a> |  | string | The full path to the file being executed in this process. [2] | `/usr/bin/cmd/otelcol`; `/usr/scripts/myscript.py` |
	| <a id="process-entrypoint" href="#process-entrypoint">`process.entrypoint`</a> |  | string | The full path to the file being executed in this process. [2] | `/usr/bin/cmd/otelcol` |

[thompson-tomo]

Yes and that is why it is the entrypoint which can be the script.

As some looking at telemetry from a script, it is of more interest to me that process A is running script XYZ then the path to the runtime given I already know the runtimr via the process.runtime attributes.

[florianl]

I think, there should be a wider discussion first for introducing process-entrypoint and not introducing it as a side-effect as part of this larger change.
With all the changes, from Release Candicate to Deprecated, this change is hardly noticeable but introduces a big change.

[thompson-tomo]

See my proposed changes in #3686 (comment) which has this as purely a rename to ensure that process.executable.* is describing an executable which is deployed to a system. The capturing of the script would be split out to future.

I agree ideally it wouldn't have been bumped but it was decided to bump everything in one go.

[thompson-tomo]

I view the process.executable.* namespace, which encompasses build_id.gnu, build_id.go, build_id.htlhash, name, and path, as a cohesive unit. Collectively, these attributes serve to uniquely identify an element.

The question is what is that element. Is it a file on the file system, if so path makes sense but the identity of the entity needs to be changed as we can't differentiate between 2 copies of the same executable at different locations. Or is it a compiled file which is distrubuted. That is what system sig decided it is. In which case path needs to move out and be about the process.

Redirecting the process.executable.build_id.* sub-namespace to process.entrypoint for executable identification does not seem appropriate.

Isn't the build_id.htlhash sufficient to uniquely identify the executable? Hence path is not needed, especially as in most cases the name is the most important as it provides meaning to the hash.

Consequently, I consider process.entrypoint to be a complementary addition rather than a replacement for process.executable.path.

The only time they differ is when a script is being run so I fail to see the need to have 2 entities for the runtime and how likely is it that a system would have 2 copies of the same runtime version on their system?

[florianl]

Redirecting the process.executable.build_id.* sub-namespace to process.entrypoint for executable identification does not seem appropriate.

Isn't the build_id.htlhash sufficient to uniquely identify the executable?

Yes - process.executable.build_id.htlhash can uniquely identify a executable. But as hashes are hard for human to comprehent and trigger actions, more descriptive attributes (like process.executable.path) are needed.

[thompson-tomo]

Yes - process.executable.build_id.htlhash can uniquely identify a executable. But as hashes are hard for human to comprehent and trigger actions, more descriptive attributes (like process.executable.path) are needed.

Agree which is why we have name on the executable to describe what the hash is referring to. On the same resource we would have the process which provides additional context including path.

Would the following alleviate your concerns:

• Change the description of the attribute as proposed in Introduce process.launch_path to replace process.executable.path #3686 (comment)
• Compliment it with either process.launch_path or process.run_path to be capturing what is being launched/run by the entrypoint.

This keeps the behaviour of executable.path as per now, ensures process.executable corresponds to the executable which is distrubuted and we have path forward on knowing the script which is being run in a process.

If happy I will limit the scope of this PR to the rename & move with the new attribute to be tackled seperately.

[github-actions]

This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days.

[braydonk]

My concern is just that this seems really hard to instrument, and really hard to implement as a general process namespace attribute. The instructions for how to parse the cmdline of the process to get the nominal "entrypoint" (like the example instructions for Python in the description) are probably going to need to exist for any runtime. Wouldn't it be better to introduce entities for the different runtimes that have their own proper instructions for determining entrypoint where that is actually useful? A majority of usecases in the general process world won't really need anything more than uniquely identifying the current executable of the process.

Compliment it with either process.launch_path or process.run_path to be capturing what is being launched/run by the entrypoint.

To my knowledge, there isn't a way to know this at any given time (short of parsing cmdline but often that doesn't actually contain the full path). You could only instrument it if you were the process yourself, guaranteeing you know when you start and reporting your own entrypoint at that point in time. Any other usecase couldn't guarantee that what they are reading is definitely the path to the executable the process was launched with.

[thompson-tomo]

The instructions for how to parse the cmdline of the process to get the nominal "entrypoint" (like the example instructions for Python in the description) are probably going to need to exist for any runtime. Wouldn't it be better to introduce entities for the different runtimes that have their own proper instructions for determining entrypoint where that is actually useful?

@braydonk This is no longer the case my updated proposal is to simply to rename the attribute and move the new attribute to the process entity. The note is made more explicit see suggestion #3686 (comment)

To my knowledge, there isn't a way to know this at any given time (short of parsing cmdline but often that doesn't actually contain the full path). You could only instrument it if you were the process yourself, guaranteeing you know when you start and reporting your own entrypoint at that point in time. Any other usecase couldn't guarantee that what they are reading is definitely the path to the executable the process was launched with.

Yes this would be an opt-in self reported descriptive attribute and it could be discussed further in the future.

For this PR we would rename process.executable.path to process.entrypoint but I'm open to alternative names ie process.launch_path and move the attribute to the process entity. There is no change to how the value is derived.

[braydonk]

my updated proposal is to simply to rename the attribute and move the new attribute to the process entity. The note is made more explicit see suggestion #3686 (comment)

I don't think we need to rename process.executable.path to add process.entrypoint, I think they're distinct. The proposal in the linked comment seems to describe process.entrypoint as being the same as /proc/[pid]/exe; to my understanding, that is explicitly not the goal of the attribute. Why can't we leave process.executable.path to mean that and process.entrypoint as a new attribute?

move the new attribute to the process entity

This attribute likely does make the most sense on the process entity, but I think we should keep process.executable.path in the process.executable entity. This attribute is different and not a sufficient replacement.

Yes this would be an opt-in self reported descriptive attribute and it could be discussed further in the future.

I guess I can get behind it as long as it's clear that default instrumentation is unlikely to report it. The attribute can be designed for situations where a given process is instrumented very specifically, and thus you understand your own rules for what process.entrypoint should be. The host_metrics receiver for example would never report this, but maybe .NET self-instrumentation would have a way to? I don't really know. But I guess the attribute can exist in the registry and on the entity as long as that's clear.

[thompson-tomo]

I think there has been some confusion/misunderstanding, let's try to straighten it out.

Process.executable.path rename

This PR seeks to rename Process.executable.path to process.launch_path, there is no change in how it is sourced. The naming is to ensure that the usage of the process.executable namespace matches the entity definition and make it clear it is what is used to launch the process.

Move attribute to process entity

This PR moves the attribute from the process.executable entity to the process entity. This is so process.executable supports the scenario of multiple identical executables on a system. If we didn' we would have un-necessary churn of the value of the descriptive attribute & could lead to wrong info. There would be no way to distinguish between the different copies on the same system.

Define entrypoint attribute for scripts*

Not in this pr but would be a future pr. yes it would have a note/brief of something like, "used to capture the full path to the script that is being run by an executable. It is designed to be captured when the script itself is instrumented and not externally observed.". It can be refined further in a future pr,

[github-actions]

This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days.

[Copilot]

Pull request overview

This PR introduces a new process attribute (process.launch_path) intended to represent the path of the file used to launch a process, while deprecating process.executable.path and updating the process entity/docs accordingly.

Changes:

• Added process.launch_path (development stability) to the process attribute registry and process entity.
• Deprecated process.executable.path (renamed to process.launch_path) and removed it from the process.executable entity surface.
• Updated generated registry/resource docs and added a changelog entry for the rename.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
model/process/registry.yaml	Adds process.launch_path attribute definition and removes process.executable.path from the primary registry.
model/process/entities.yaml	Associates process.launch_path with the process entity and removes process.executable.path from process.executable.
model/process/deprecated/registry-deprecated.yaml	Adds a deprecated entry for process.executable.path renamed to process.launch_path.
docs/resource/process.md	Documents process.launch_path in the Process resource documentation.
docs/registry/entities/process.md	Updates process entity registry docs (adds process.launch_path, removes process.executable.path from executable entity).
docs/registry/attributes/process.md	Updates process attribute registry docs (adds process.launch_path, marks process.executable.path deprecated).
docs/cli/cli-spans.md	Marks process.executable.path as deprecated in CLI span docs (but still lists it as Recommended).
.chloggen/process_entrypoint.yaml	Adds changelog entry describing the rename/replacement.

[opentelemetry-pr-dashboard]

Pull request dashboard status

Status last refreshed: 2026-07-25 20:01:49 UTC.

• Waiting on: Author
• Next step: Address or respond to 2 review feedback items:
  • Inline threads: 1
  • Top-level feedback: 2
  • For each item, reply to move the discussion forward, e.g. link to the commit that addresses it, explain why no change is needed, or ask a follow-up question.

This automated status or its linked feedback items may be incorrect. If something looks wrong, please report it with the result you expected. If you believe this pull request is incorrectly routed as waiting on the author, comment /dashboard route:reviewers to route it from waiting on the author to waiting on reviewers. If the last refreshed time above predates your latest reply or push, the dashboard hasn't processed it yet.

[braydonk]

This PR seeks to rename Process.executable.path to process.launch_path, there is no change in how it is sourced.

That's actually even more incorrect. The expected instrumentation for the process entity could never tell at any given time that the detected executable for the process is the same as the path that it was launched with. It could be changed at any time. So the name is very misleading, and as written I don't think it should be on the entity.

This PR moves the attribute from the process.executable entity to the process entity. This is so process.executable supports the scenario of multiple identical executables on a system. If we didn' we would have un-necessary churn of the value of the descriptive attribute & could lead to wrong info. There would be no way to distinguish between the different copies on the same system.

But you still can't do that. Removing process.executable.path from the process.executable entity doesn't make it so you are able to do that. You have a very similar problem as before. You get rid of the path as a churn, but two different copies of the executable would still look like one to the backend since the only identifying attributes are the hash and build ID.

If you want to distinguish between two copies of an executable on the system (not just an executable, ANY kind of file) the only fundamentally correct way to do so is by that file's unique ID (inode on Linux, file index on Windows, etc). The path, or lack thereof, is never a good way to truly uniquely identify a file on an operating system.

Not in this pr but would be a future pr. yes it would have a note/brief of something like, "used to capture the full path to the script that is being run by an executable. It is designed to be captured when the script itself is instrumented and not externally observed.". It can be refined further in a future pr,

I am only okay with the attribute process.launch_path on any entity if this is its exclusive purpose. If it's an opt-in attribute with special instructions it might work. Even still, I would rather it lived on process.runtime than process. The idea of a "launch path" is not a fundamental concept of an operating system process.

[rogercoll]

I am not aware of any information in Linux (/proc filesystem) to retrieve the initial executable path for a given process/pid. The vale of process.executable.path can change over the process entity lifetime. In that sense, readlink the symbolick link in /proc/self/exe does not guarantee that it was the initial executable (execv syscall changes that value).

Any idea of how this will be retrieved?

[thompson-tomo]

I am more than happy to loosen the note to remove initial hence it can be updated. In fact would run_path be a better name option for you that way can say it is path to what is running in the process.

[rogercoll]

What would be the difference from using process.executable.path? The attribute is part of the process namespace, therefore it always depends on the running process (implicit that it might change over time).

[thompson-tomo]

Removing process.executable.path from the process.executable entity doesn't make it so you are able to do that. You have a very similar problem as before. You get rid of the path as a churn, but two different copies of the executable would still look like one to the backend since the only identifying attributes are the hash and build ID.

That is fine & it is expected given this pr is not seeking to differentiate between 2 copies of the same file. I am well aware we need a more robust way to identify the instance of a file but out of scope for this pr.

The expected instrumentation for the process entity could never tell at any given time that the detected executable for the process is the same as the path that it was launched with. It could be changed at any time. So the name is very misleading, and as written I don't think it should be on the entity.

If you are not a supporter of process.launch_path what about process.run_path/process.running_path that way we can say it is path to what is running in the process? Or is another new name you would prefer @braydonk which doesn't overlap with the process.executable

Even still, I would rather it lived on process.runtime than process.

It couldn't live on runtime as we end up back in the situation of the descriptive attribute belonging to a different item than the identity. Anyway That is a seperate discussion for a different pr.

Key thing here is what should the attribute be called which describes the path to what is running in a process.

[braydonk]

If you are not a supporter of process.launch_path what about process.run_path/process.running_path that way we can say it is path to what is running in the process?

My favourite option is to keep it named process.executable.path. That's a literal description of what it is that matches common nomenclature.

P.S. I think process.executable.name and process.executable.path being attributes on process.executable is actually kind of weird; process.executable.path is a reasonable name here because when describing this property of a process, yes it is the current path to the process's executable. But a process.executable entity is nominally just representing a file, so there is no reason for attributes like process.executable.path and process.executable.name to exist separate from simply file.path and file.name.

[thompson-tomo]

My favourite option is to keep it named process.executable.path.

Then we have 2 usages/meanings for process.executable, what about process.executing_path or process.execution_path? That way it is clearly related to executable but not identical namespaces.

P.S. I think process.executable.name and process.executable.path being attributes on process.executable is actually kind of weird

The problem is profiling needs to be able to get a name for the executable identified by the id.

The options i see to improve things:

• rename process.executable.path (see new suggestions) & add it to process
• move path/name back to process & rename profiling attributes & entity. Maybe process.symbol.*

[braydonk]

Then we have 2 usages/meanings for process.executable

It's not really different. It is the path to the process's executable. It's about an executable. That's not ambiguous to me at all.

what about process.executing_path or process.execution_path?

Not a fan of those; non-standard nomenclature, and could be very confusing. What we're trying to describe is "the path to the executable run by the process", so calling that "execution path" isn't exactly stating that clearly.

The problem is profiling needs to be able to get a name for the executable identified by the id.

Yeah the process.executable entity can have a name and path, I think that's fine. My problem with the process.executable entity is that most of its properties are just normal properties of a file. Having special process.executable attributes for path and name don't make sense on that entity when you could communicate identical information with file.path and file.name. process.executable.path is a name that made sense in context of the process entity itself, because a "process" has an "executable" that it's running and you can retrieve the "path" to it. But all of that relevance was erased when they moved into a separate entity describing the executable on its own.