mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-26 01:26:00 +03:00
[GH-ISSUE #376] Bugfix: Crome crashes inside of docker #1769
Labels
No labels
expected: maybe someday
expected: next release
expected: release after next
expected: unlikely unless contributed
good first ticket
help wanted
pull-request
scope: all users
scope: windows users
size: easy
size: hard
size: medium
size: medium
status: backlog
status: blocked
status: done
status: idea-phase
status: needs followup
status: wip
status: wontfix
touches: API/CLI/Spec
touches: configuration
touches: data/schema/architecture
touches: dependencies/packaging
touches: docs
touches: js
touches: views/replayers/html/css
why: correctness
why: functionality
why: performance
why: security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ArchiveBox#1769
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @1n5aN1aC on GitHub (Jul 21, 2020).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/376
Describe the bug
PDF and Screenshot generation failing. (It seems like some of them complete eventually on subsequent attempts)
400MB+ "core" files are left in directories when those failures happen.
Steps to reproduce
This is a new install of ArchiveBox, (First time trying it) using the dockerHub image. (nikisweeting/archivebox)
The default capture in the docker-compose fails as well: (
command: bash -c 'echo "https://github.com/pirate/ArchiveBox" | /bin/archive; tail -f /dev/null')Screenshots or log output
First entry succeeds (at least for pdf+screenshot) second does not:
Software versions
10799e4@pirate commented on GitHub (Jul 21, 2020):
This is sometimes due to lack of RAM on low-powered devices, or the older Chrome build in that docker image being incompatible with an unusual architecture (When Chrome crashes it core-dumps to disk, which leaves those large files).
Can you try on v0.4.3 (the next release coming out this week).
@1n5aN1aC commented on GitHub (Jul 21, 2020):
This is on a "relatively-standard" device (amd64 / Ryzen) and should have plenty of ram. (32GB Installed, most of that available)
The Chrome thing seems somewhat likely, I will try it now.
@1n5aN1aC commented on GitHub (Jul 21, 2020):
Seems to be the same result as before:
root@LOCALHOST:~/deleteme/ArchiveBox# uname -a
Linux LOCALHOST 5.7.0-1-amd64 #1 SMP Debian 5.7.6-1 (2020-06-24) x86_64 GNU/Linux@pirate commented on GitHub (Jul 21, 2020):
Ok, I suspect it's running out of shared memory (the docker default is 64MB regardless of how much RAM you have).
Try launching it with the
--shm-size 512Mflag like so:If that works, then it confirmed shared memory was the limitation and we can either add that to the docker setup or update chrome to no use shared memory like so
--disable-software-rasterizer --disable-dev-shm-usage.@1n5aN1aC commented on GitHub (Jul 22, 2020):
Very sorry for forgetting to set a name for the issue!
Yes,
--shm-size 512Mdoes resolve the issue, thank you very much!Here was my solution to configure this in docker-compose:
However, it should be noted, (possibly added to documentation?) that this solution requires your docker-compose.yml file to be
version: '3.5'at a minimum. (not just '3')@pirate commented on GitHub (Jul 22, 2020):
Fixed in
8cb5302. You can remove theshm_size: '512m'falg from your docker setup, I disabled SHM usage inside containers using chrome cli args.@ttimasdf commented on GitHub (Sep 22, 2020):
Tested on
b18bbf8874,shm_sizeparameter is still needed for Chromium to work. Screenshot is okay without it, but it's still required for PDF output.