Skip to content

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

Open
bhanutejagk wants to merge 2 commits into
mainfrom
fix/sglang-amzn2023-console-scripts
Open

fix(sglang): ship sglang/killall_sglang console-scripts in amzn2023 runtime image#6503
bhanutejagk wants to merge 2 commits into
mainfrom
fix/sglang-amzn2023-console-scripts

Conversation

@bhanutejagk

@bhanutejagk bhanutejagk commented Aug 7, 2026

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

Verified in CI. Both amzn2023 images build successfully, and the previously-failing upstream-tests / srt-backend-test now passes on both the ec2-amzn2023 and sagemaker-amzn2023 variants (it was failing with FileNotFoundError: 'sglang'). Sanity tests (including SageMaker sanity) and the ECR vulnerability scan also pass.

…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
bhanutejagk enabled auto-merge (squash) August 8, 2026 00:29
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