mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-26 09:36:01 +03:00
[GH-ISSUE #1604] Bug: Chrome times out saving https://www.rover.com/ because of --virtual-time-budget=15000, causing SingletonFile lock contention breaking future launches #2468
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#2468
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 @nguyenmp on GitHub (Nov 24, 2024).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1604
Originally assigned to: @pirate on GitHub.
Provide a screenshot and describe the bug
With the current default settings, Chrome will hang trying to save https://www.rover.com/. This is triggered by the
--virtual-time-budget=15000argument. Removing this argument allows chrome to archive the DOM as desired.However, there's a pathological case here! When we hang forever trying to save Rover.com, it causes the persona to get locked. ArchiveBox times out the action and moves on to the next one which runs into the singleton file and fails. As mentioned in https://github.com/ArchiveBox/ArchiveBox/issues/1599#issuecomment-2495062208, this pathological case would go away if we used a temp personal directory each time.
I think this was added to work around full page screenshot issues. I just wanted to share this example in case this is a more common problem and maybe the default would be reconsidered. I'm not arguing one way or another, but it's probably worth tracking how many websites hit this issue.
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?
macOS (including Docker on macOS)
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.)@pirate commented on GitHub (Nov 25, 2024):
Already started building this! The new
archivebox/personasapp is a dedicated app to handle creating "template" chrome profiles that get copied to a unique tmp dir each time a new chrome instance is launched. Should solve theSingletonLockissue completely if it works.I'm also planning on removing the
--virtual-time-budget=15000arg completley as it's caused other issues in the past@pirate commented on GitHub (Dec 30, 2025):
I removed the
--virtual-time-budget=15000arg completely on dev