fix(examples): cherry-pick Triton CUDA 13 image + libdcgm copy (#12577)

[dagil-nvidia]

Summary

Cherry-pick of #12577 (ba294ab0d9, merged to main 2026-08-03 22:19 UTC) onto release/1.4.0.

Clears P0 NVBug 6541824 / DYN-3697: the Triton example container cannot start because of a CUDA ABI mismatch.

Applies clean, no conflicts. Diff is identical to #12577: 2 files, +18/-7. Authorship preserved (@nealvaidya), -x records the source commit.

What it fixes

The image bump alone is not sufficient. tritonserver:25.10-py3 ships libdcgm.so.4 under /usr/lib/x86_64-linux-gnu rather than /lib/…, so the previous COPY glob would silently match nothing. The bind-mount plus find -exec cp -a handles the merged-usr move and preserves the symlink chain.

The build-time import tritonserver check turns the reported symptom into a build gate, so a future base-image CUDA bump fails loudly rather than shipping a container that cannot start.

The README run-path change is a second real fix: launch/ is copied to /workspace/launch/ with WORKDIR /workspace, so the previous ./examples/backends/tritonserver/launch/identity.sh path did not exist inside the container.

History

Originally opened staged ahead of main, picking the two pre-merge commits. Re-picked from the squash commit once #12577 landed, so the provenance trailer points at the real merged SHA. Content unchanged.

[devin-ai-integration]

Devin Review found 2 potential issues.

[devin-ai-integration]

🟡 Missing GPU monitoring libraries no longer stop the image build, producing a container that fails to start

The libraries are copied with a search-and-copy step that succeeds even when nothing is found (find ... -exec cp -a at examples/backends/tritonserver/Dockerfile:16-17) instead of the previous copy that failed the build on no match, so an image missing these libraries is built and shipped silently.
Impact: If a future base image relocates or drops these libraries, the build still passes and the failure only surfaces when users run the container.

Why the failure mode changed: COPY glob vs. find -exec

Previously COPY --from=triton_source /lib/x86_64-linux-gnu/libdcgm*.so* ... errored out at build time when the glob matched no file. The replacement bind-mounts /usr/lib/x86_64-linux-gnu from the Triton stage and runs find /triton_usr_lib -name "libdcgm*.so*" -exec cp -a {} /lib/x86_64-linux-gnu/ \;. find exits 0 when it matches nothing, so the layer succeeds with zero files copied. A guard such as failing when the match count is zero (for example capturing the found paths and testing that the list is non-empty) restores the loud build-time failure the change intends to preserve.

Suggested change

	RUN --mount=type=bind,from=triton_source,source=/usr/lib/x86_64-linux-gnu,target=/triton_usr_lib \
	find /triton_usr_lib -name "libdcgm*.so*" -exec cp -a {} /lib/x86_64-linux-gnu/ \;
	RUN --mount=type=bind,from=triton_source,source=/usr/lib/x86_64-linux-gnu,target=/triton_usr_lib \
	found=$(find /triton_usr_lib -name "libdcgm*.so*") && \
	[ -n "$found" ] && \
	find /triton_usr_lib -name "libdcgm*.so*" -exec cp -a {} /lib/x86_64-linux-gnu/ \;

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔍 Build-time import tritonserver may require CUDA driver libraries not present during docker build

The new gate RUN python3 -c "import tritonserver" (examples/backends/tritonserver/Dockerfile:32) loads libtritonserver.so, which pulls in CUDA runtime and DCGM shared objects. Driver libraries (/usr/local/nvidia/lib64, libcuda.so.1) are injected by the NVIDIA container runtime at run time, not during docker build. If the import path touches any driver-linked symbol, the build would fail on ordinary CPU-only builders/CI. Worth confirming the check was exercised on a builder without GPU support before this becomes a hard build gate for everyone.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[github-actions]

🌿 Fern Docs Preview: https://nvidia-preview-019fc9c1-ad20-72fa-8f29-9959508c0a49.docs.buildwithfern.com/dynamo/dev