Sitelet https://github.com/moby/moby/pull/53423
Skip to content

daemon/nri: populate Container.Args with full resolved process argv - #53423

Open
bbartels wants to merge 1 commit into
moby:masterfrom
bbartels:nri-container-metadata-fix
Open

daemon/nri: populate Container.Args with full resolved process argv#53423
bbartels wants to merge 1 commit into
moby:masterfrom
bbartels:nri-container-metadata-fix

Conversation

@bbartels

Copy link
Copy Markdown

Summary

NRI plugins receive container metadata whose Args field was populated from Config.Cmd only, omitting the entrypoint/executable. Plugins therefore couldn't determine the actual launched process, and the metadata diverged from the argv Moby places in the OCI runtime spec:

docker run --rm --entrypoint echo alpine hello
# launched process: ["echo", "hello"]
# NRI plugin saw:   ["hello"]

Changes

  • daemon/internal/nri/nri.gocontainerToNRI now builds Args from the container's resolved launch fields:

    - Args:         ctr.Config.Cmd,
    + Args:         append([]string{ctr.Path}, ctr.Args...),
    • ctr.Path/ctr.Args are resolved from Entrypoint/Cmd by daemon.newContainer (getEntrypointAndArgs) before daemon.nri.CreateContainer runs, so they are always populated at conversion time.
    • Construction matches the OCI process args exactly (daemon/oci_linux.go, daemon/oci_windows.go: append([]string{c.Path}, c.Args...)).
    • Appending onto a fresh slice literal allocates a new backing array, so NRI metadata does not alias the container's mutable argument slices.
    • Empty/invalid-command semantics are unchanged; such configs are rejected before container creation.
  • daemon/internal/nri/nri_test.go (new) — unit tests for containerToNRI covering:

    • explicit entrypoint override (["echo"] + ["hello"]["echo", "hello"])
    • image entrypoint with args plus cmd (["/usr/bin/tool", "--mode"] + ["input"])
    • cmd-only and entrypoint-only containers (no dropped/duplicated argv[0])
    • consistency with the OCI-spec argv construction
    • slice ownership: mutating NRI args does not modify the container's resolved args

Backward compatibility

Behavior change for plugins that assumed Args[0] was the first Docker Cmd argument — Args now includes the executable at index zero. Docker's NRI support is experimental; this aligns the metadata with the launched process. ContainerAdjustment.Args handling and CLI Entrypoint/Cmd semantics are untouched.

Release notes (optional)

Fix NRI container metadata so `Container.Args` includes the resolved executable as `argv[0]`, matching the process launched in the container instead of only the Docker `Cmd`.

Created with: GitHub Copilot Task Agent

@thaJeztah

Copy link
Copy Markdown
Member

Looks like the PR contains commits unrelated to this change (and various merge commits); can you clean that up?

Build NRI container metadata from the daemon's resolved process path and arguments so plugins observe the same argv used by the OCI runtime spec. Add coverage for entrypoint and command combinations and verify that the exported slice does not alias container state.

Signed-off-by: Benjamin Bartels <benjamin@bartels.dev>
@bbartels
bbartels force-pushed the nri-container-metadata-fix branch from 5877dfe to 3bf1d6e Compare August 20, 2026 20:21
@bbartels

Copy link
Copy Markdown
Author

Cleaned up and force-pushed the branch as a single signed-off commit based on current master. The PR now contains only the two intended NRI files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants