mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-25 09:06:02 +03:00
[GH-ISSUE #1622] Bug: New/re snapshots failing #2481
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#2481
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 @parkerlreed on GitHub (Dec 20, 2024).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1622
Originally assigned to: @pirate on GitHub.
Provide a screenshot and describe the bug
New or updating snapshots are failing
Steps to reproduce
Logs or errors
ArchiveBox Version
How did you install the version of ArchiveBox you are using?
Docker (or other container system like podman/LXC/Kubernetes or TrueNAS/Cloudron/YunoHost/etc.)
What operating system are you running on?
Linux: Arch Linux
What type of drive are you using to store your ArchiveBox data?
data/is on a local SSD or NVMe drivedata/is on a spinning hard drive or external USB drivedata/is on a network mount (e.g. NFS/SMB/CIFS/etc.)data/is on a FUSE mount (e.g. SSHFS/RClone/S3/B2/OneDrive, etc.)Docker Compose Configuration
ArchiveBox Configuration
@rcarmo commented on GitHub (Jan 8, 2025):
I've noticed the same ever since I updated my Docker image 0.7.3. There is something broken in the new dependencies, perhaps.
@pirate commented on GitHub (Jan 9, 2025):
What browser are you using out of curiosity to access the UI?
Safari has had issues in the past submitting checked snapshot IDs correctly when Admin UI buttons are clicked.
@parkerlreed commented on GitHub (Jan 9, 2025):
Firefox on Linux
@rcarmo commented on GitHub (Jan 9, 2025):
I did a little more digging on this and (since I'm using the
stablecontainer image) set up anovnccontainer so I could see if Chrome was taking to long to load, etc.I tried snapshotting a public gist while I was watching the VNC screen, and Chrome launched instantly, then just sat there for 60s until the timeout, then was launched again (I have PDFs and screenshots turned on), etc.
I then looked at the container logs, and the progress bar instantly shoots to 97.5% and then just sits there for 59 seconds.
The web log showed:
I reverted to the 0.7.1 container image (in headless mode) and everything worked, so I tried again with 0.7.2 (also in headless mode) and it also worked.
Something is broken in the code that is not orchestrating the browser correctly, or not getting the output, and judging from my history, it happened with the 0.7.3 dependency update.
@pirate commented on GitHub (Jan 9, 2025):
That sounds like you're running into one of the forms of this ssue:
Despite the title implying it's only an issue with hanging on exit, I've also seen this issue manifest as hanging on launch and not doing anything when in headful mode.
@rcarmo do you have any
CHROME_USER_DATA_DIRset? and what CPU architecture are you on?Also can ya'll try setting
CHROME_HEADLESS = Truemanually in the config and running again?@rcarmo commented on GitHub (Jan 10, 2025):
@pirate no to
CHROME_USER_DATA_DIR, the container is on an Intel box.@parkerlreed commented on GitHub (Jan 10, 2025):
Adding the headless flag does seem to work. Was able to run a new task.