mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-25 09:06:02 +03:00
[GH-ISSUE #1699] Bug: SQLite db disk image requires repair when macOS interrupts container without clean shutdown #4031
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#4031
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 @Scribbd on GitHub (Oct 12, 2025).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1699
Originally assigned to: @pirate on GitHub.
Provide a screenshot and describe the bug
I am aware of #955, and that the documentation has a working fix. This ticket is to add more information about this bug, as I can reproduce it with some consistency. The uncertainty is what gives rise to my hypothesis, as I think it is an unfortunate timing issue. It has happened to me three times, and I can always link it back to when I leave my device unattended for a while. Either I forget I have an archiving job running and close the lid. Or having the screen locked with the power plugged in(?: see steps to reproduce; I have a battery management app).
My hypothesis is that some external power management process interrupts/sleeps one of the ArchiveBox processes and puts it and the DB in a state from which it cannot recover. This can either be macOS power management or the Docker Desktop sleep feature.
Some details on my setup: I run a modified docker-compose stack that has some health checks and dependencies added. The first few times the database got malformed, I deleted the archivebox data folder and started the stack to rebuild the folder from scratch. Only to be met with an error akin to
cannot init folder that isn't empty, while havingrm -rfd-ed the folder. This addition seemed to resolve the issue. I suspect that there might be a race condition between the scheduler and the main container.Steps to reproduce
Logs or errors
ArchiveBox Version
How did you install the version of ArchiveBox you are using?
Docker (or Podman/LXC/K8s/TrueNAS/Proxmox/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/Ceph/GlusterFS/etc.)data/is on a FUSE mount (e.g. SSHFS/RClone/S3/B2/Google Drive/Dropbox/etc.)Docker Compose Configuration
ArchiveBox Configuration
@pirate commented on GitHub (Oct 16, 2025):
Interesting thanks for the additional info. I still have never been able to replicate this personally. I use an M1 MacBook Pro as my daily driver and often sleep/wake it without pausing containers. I don't use Aldente Pro or Caffinate, but I do use
Amphetamine.appoccasionally which is probably similar.For anyone who stumbles across this later, the docs in question that describe the fix are here:
https://github.com/ArchiveBox/ArchiveBox/wiki/Troubleshooting#repairing-a-corrupted-sqlite3-database-file