mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-25 09:06:02 +03:00
[GH-ISSUE #1524] Bug: Unable to start server without supervisord #3923
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#3923
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 @prurigro on GitHub (Sep 25, 2024).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1524
Describe the bug
There now appears to be a hard dependency on supervisord for
archivebox server, meaning that most distros running archivebox outside of docker won't be able to use the server feature.Steps to reproduce
archivebox server --init 0.0.0.0:8888AssertionError: Failed to start supervisord or connect to it!Screenshots or log output
ArchiveBox version
The version is the latest git master (COMMIT_HASH shows as "unknown" in the --version output below)
@pirate commented on GitHub (Sep 25, 2024):
Yes this is intentional, the new server is much more advanced than the old one and spawns a pool of several background workers now.
Why do you say distros won't be compatible outside of docker? Supervisord is readily available via pip, and is a pip dependency like any other. It does not depend on having a global supervisord daemon that's started at boot, so there's no expectation of a new apt/pkg install or any changes to the host's systemd/init system config.
Our use of supervisord is strictly as a sub process spawned when the server starts, using only the pip library and local config inside the /data folder, nothing is touched in /etc.
In fact, how did you manage to install it without supervisord (considering it's in the pip requirements for 0.8.4)?
(Also side note, the 09-11 build you're running is already 10k+ lines of changes behind 09-25 :dev 😀, this has probably the most active month of archivebox development in the project's history.)
@prurigro commented on GitHub (Sep 25, 2024):
Ahh, my mistake! The supervisord website made it look like it was a system-level service manager like systemd, and I wasn't able to find a package for it (turns out it's "supervisor" and not "supervisord").
It actually looks like it was installed, but it's in the pipx container's bin folder (from which only the archivebox executable is symlinked to ~/.local/bin/). I would have thought pipx would have had a trick for loading a package's own bin into $PATH while it's executing, but injecting that into a little wrapper before calling archivebox seems to do the trick!
Apologies for the confusion and thanks for pointing me in the right direction :) Also, thanks for keeping this project maintained, it's an awesome piece of kit :) I'll have to pull in the latest changes!
@pirate commented on GitHub (Sep 25, 2024):
Ok that makes sense, no worries, I can easily fix that pipx issue on my side, archivebox actually includes a whole interface with pipx now so I have code already to handle that case. I'll set it to auto find the supervisor binary in the pipx path like it does for things like ytdlp/playwright/etc and other runtime dependencies used for the extractors.
@JitteryDoodle commented on GitHub (Oct 15, 2024):
Is it odd that I'm getting the "failed to start supervisord or connect to it!" error message when using the docker container on the dev branch?
@michaeltieso commented on GitHub (Oct 16, 2024):
Has there been any updates to this? I'm getting the same issue on the dev branch.
@pirate commented on GitHub (Oct 16, 2024):
Huh I pushed several fixes that should work for the earlier issue, so it's likely a different original cause or at least some new bug.
Can you open a new issue plz with logs and version output.