Skip to content

fix(sglang): ship sglang/killall_sglang console-scripts in amzn2023 runtime image - #6502

Closed
bhanutejagk wants to merge 1 commit into
aws:mainfrom
bhanutejagk:fix/sglang-amzn2023-console-scripts
Closed

fix(sglang): ship sglang/killall_sglang console-scripts in amzn2023 runtime image#6502
bhanutejagk wants to merge 1 commit into
aws:mainfrom
bhanutejagk:fix/sglang-amzn2023-console-scripts

Conversation

@bhanutejagk

Copy link
Copy Markdown
Contributor

Root cause

docker/sglang/Dockerfile.amzn2023 is multi-stage. The builder stage runs an editable install (uv pip install --system -e "python[all]"), which generates the sglang and killall_sglang console-scripts into the builder's /usr/local/bin. The runtime stage copies site-packages and explicitly copies only the sglang-router binary — it never copies sglang/killall_sglang.

As a result the shipped amzn2023 image declares a sglang CLI (entry point sglang.cli.main:main) that is not on PATH. Any invocation of subprocess.Popen(['sglang', 'serve', ...]) fails with FileNotFoundError: 'sglang'.

Both the ec2-amzn2023 and sagemaker-amzn2023 images build from this shared Dockerfile.amzn2023, so this single change fixes both.

Fix

Copy the two console-scripts from the builder stage into the runtime stage, immediately after the existing sglang-router copy:

COPY --from=builder /usr/local/bin/sglang /usr/local/bin/sglang
COPY --from=builder /usr/local/bin/killall_sglang /usr/local/bin/killall_sglang

Why fix the image instead of the test?

The registered upstream tests are pulled from upstream at the same ref the image builds from, so there is no version skew to manage. Upstream now advertises sglang serve as the canonical entrypoint, while python -m sglang.launch_server prints a legacy-fallback notice. Shipping the sglang CLI that the package already declares is the correct fix; patching the test would paper over a genuine gap in the image and drift from upstream's documented interface.

Customer impact

None. Customer entrypoints today use python -m sglang.launch_server, which continues to work unchanged. This change only adds the missing sglang/killall_sglang scripts to PATH.

Scope

  • The Ubuntu docker/sglang/Dockerfile is not affected — it is single-stage on top of the upstream base image, which already provides sglang — and is not modified.

Build status

Build-unverified: no full from-source GPU rebuild was run for this change. The diff is a two-line file-copy in the runtime stage and does not alter the build graph.

…untime image

The amzn2023 image is multi-stage. The builder stage runs an editable
install (`uv pip install --system -e "python[all]"`), which generates the
`sglang` and `killall_sglang` console-scripts in the builder's
/usr/local/bin. The runtime stage copies site-packages and only the
`sglang-router` binary, so the `sglang` CLI declared by the package
(entry point `sglang.cli.main:main`) is absent from PATH in the shipped
image. Copy both console-scripts from the builder stage so the advertised
CLI is available at runtime.

The Ubuntu Dockerfile is unaffected (single-stage base image already
provides the CLI) and is not changed.
@bhanutejagk

Copy link
Copy Markdown
Contributor Author

Superseded by #6503 — moved to an upstream branch so CI can authenticate and build (fork PRs lack the repo secrets/region creds the DLC build jobs need).

@bhanutejagk bhanutejagk closed this Aug 7, 2026
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.

1 participant