[Bug]: arm64 image ships ~2.4GB of build-time waste (core dumps + duplicate Chromium cache), root-caused to QEMU CI emulation
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 62/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- docker, github-actions, playwright, python
- Ambito
- ci-cd, devops, infrastructure
Direzione di ricerca
Start with the arm64 build configuration in .github/workflows/docker-release.yml and locate the steps that install and copy Playwright browsers during the image build. Reproduce the reported sizes with docker history and du, then verify that the arm64 image has no /app/*.core files or unused /root/.cache/ms-playwright copy while the appuser browser cache remains usable.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
crawl4ai version
0.9.2
Expected Behavior
The published arm64 Docker image should only contain files needed at runtime. Build/test artifacts (crash dumps from the crawl4ai-doctor sanity check) and intermediate install artifacts (the root-owned Playwright browser cache, superseded by the copy made for appuser) should be cleaned up before the image layers are committed.
Current Behavior
unclecode/crawl4ai:latest (arm64) reports as 9.06GB via docker images. Inspecting a freshly-pulled container shows two separate sources of dead weight, totaling ~2.4GB of its ~5.5GB live filesystem:
- Core dumps in /app (~926MB)
-r--r--r-- root root 510M /app/qemu_headless_shell_20260715-085214_28.core
-r--r--r-- root root 208M /app/qemu_headless_shell_20260715-085211_34.core
-r--r--r-- root root 208M /app/qemu_headless_shell_20260715-085211_32.core
- These are dated at image build time, not container runtime, and are root-owned/read-only, so end users can't remove them from a running container.
- Duplicate Chromium install (~1.5GB)
1.5G /root/.cache/ms-playwright (dead - root never runs; container runs as appuser)
958M /home/appuser/.cache/ms-playwright (actually used at runtime)
playwright install --with-depsinstalls the browser to/root/.cache(running as root during build), then a laterRUN step cp -r's it to/home/appuser/.cachefor the actual runtime user, but never deletes the original. Both copies ship in the final image.
Is this reproducible?
Yes
Inputs Causing the Bug
N/A — not input-dependent. Present in every pull of the arm64 image, not triggered by user config.
Steps to Reproduce
Steps to Reproduce:
1. docker pull unclecode/crawl4ai:latest
2. docker run --rm -it unclecode/crawl4ai:latest bash
3. ls -lh /app/*.core
4. du -sh /root/.cache/ms-playwright /home/appuser/.cache/ms-playwright
Code snippets
docker history — confirms duplicate layer cost:
$ docker history --no-trunc unclecode/crawl4ai:latest | grep -E "chown -R root|cp -r.*ms-playwright"
972MB RUN chown -R root:root ${APP_HOME} && chmod -R a-w ${APP_HOME}
1GB RUN mkdir -p /home/appuser/.cache/ms-playwright \
&& cp -r /root/.cache/ms-playwright/chromium-* \
/root/.cache/ms-playwright/chromium_headless_shell-* \
/home/appuser/.cache/ms-playwright/ \
&& chown -R appuser:appuser /home/appuser/.cache/ms-playwright
docker-release.yml — confirms cross-arch QEMU build:
$ grep -A3 "platforms:" .github/workflows/docker-release.yml
platforms: linux/amd64,linux/arm64
cache-from: type=gha
cache-to: type=gha,mode=max
OS
Linux (Raspberry Pi OS, arm64
Python version
3.12
Browser
Chromium (bundled headless_shell, via Playwright build 1228)
Browser version
149.0.7827.0
Error logs & Screenshots (if applicable)
docker history shows the chown -R root:root $APP_HOME && chmod -R a-w $APP_HOME layer at 972MB, matching the ~926MB of .core files in /app. du -sh on a running container shows /root/.cache/ms-playwright (1.5G) and /home/appuser/.cache/ms-playwright (958M) as separate, duplicate browser installs
- Lingua principale
- Python
- Stelle
- 84.5k
- Fork
- 8.7k
- Merge medio
- 3g 4h
- PR unite (30g)
- 14
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di unclecode/crawl4ai
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
unclecode/crawl4ai#2326 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
🐞 Bug 🩺 Needs Triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
unclecode/crawl4ai#2319 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
[Bug]: Reusing BFSDeepCrawlStrategy leaks the previous crawl's max_pages budget into a fresh runAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
unclecode/crawl4ai#2309 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100
unclecode/crawl4ai#2147 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
unclecode/crawl4ai#2123 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di unclecode/crawl4ai
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
BasedHardware/omi#20271 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 92/100
openai/openai-cookbook#3153 ·
I maintainer di solito rispondono entro 1 giorno
-
cvss-severity:high devguard l3montree-cybersecurity/devguard/devguard pkg:golang/github.com/l3montree-dev/devguard risk:low state:open
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
l3montree-dev/devguard#3146 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
-
bug confirmed issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
open-webui/open-webui#31849 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno