You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bug: openshell sandbox create --from OOM-killed on large images #602
Investigated using the create-spike skill backed by principal-engineer-reviewer. Skills loaded: debug-openshell-cluster, openshell-cli, create-spike.
Traced sandbox create --from through run.rs → build.rs → push.rs
Confirmed three discrete full-image heap allocations in push_local_images() at push.rs:54–55
Verified bollard::upload_to_container accepts body_try_stream() — no API constraint blocks a streaming fix
Confirmed the tar crate size-in-header constraint requires a seekable (disk) intermediate; fully in-memory zero-copy is not feasible
Found tempfile is already a dev-dep; needs promotion to prod dep
No test coverage exists for push.rs
Description
Running openshell sandbox create --from <dockerfile-dir> on a large sandbox image (~3.7 GB) causes the openshell process to be killed by the Linux OOM killer. The image export pipeline in crates/openshell-bootstrap/src/push.rs buffers the entire Docker image tar three times in memory before importing it into the gateway, producing ~11 GB peak allocation.
The three allocations in push_local_images():
collect_export (push.rs:97–107) — streams docker.export_images() into a Vec<u8> (~3.7 GB)
wrap_in_tar (push.rs:114–131) — copies that Vec<u8> into a second tar-wrapped Vec<u8> (~3.7 GB); both are live simultaneously, peak ~7.4 GB
upload_archive (push.rs:135–151) — calls Bytes::copy_from_slice(archive) creating a third copy (~3.7 GB); all three overlap in scope, peak ~11 GB
Expected: the export → tar wrap → upload pipeline streams data in O(chunk) memory.
Reproduction Steps
Build a large sandbox image (≥ 3 GB uncompressed):
I suggest refactoring this into a streaming pipeline—likely using tempfile to handle the tar header size requirement while keeping RAM usage constant. This would allow the process to handle multi-GB images with minimal memory footprint.
Activity
openshell sandbox create --fromOOM-killed on large images due to in-memory image buffering #600 as a duplicate of this issueopenshell sandbox create --fromOOM-killed on large images #601 as a duplicate of this issueminhdqdev commentedon Mar 27, 2026
I suggest refactoring this into a streaming pipeline—likely using tempfile to handle the tar header size requirement while keeping RAM usage constant. This would allow the process to handle multi-GB images with minimal memory footprint.
I can put a PR to fix it.