mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-25 17:16:00 +03:00
[GH-ISSUE #1544] Bug: failing to start supervisord in v0.8.5rc44 #2425
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#2425
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 @tdec on GitHub (Oct 17, 2024).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1544
Describe the bug
supervisord fails to start with v0.8.5rc44 Docker build
Steps to reproduce
Screenshots or log output
The content of the directory the script is looking for is
The local data directory is a drive mounted over USB
/dev/sdb2 on /mnt/sdb2 type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)ArchiveBox version
@pirate commented on GitHub (Oct 17, 2024):
Please run
chown -R 911 dataoutside of docker. If possible also change your fstab entry to not force the volume ownership to be 0:0, ideally use 911:0. (If not 911 then set the PUID env var to the value you prefer)Archivebox does not work with volumes that are forcibly set to root ownership as it always tries to drop permissions to a non root user at startup.
There is some info in the troubleshooting docs in the wiki about this.
@pirate commented on GitHub (Oct 17, 2024):
Here's the relevant docs: https://github.com/ArchiveBox/ArchiveBox/wiki/Configuration#puid--pgid
The fstab entry you have is basically the same as root_squash on an NFS mount, it's forcing ownership to 0:0, which may prevent ArchiveBox from changing it to 911:0.
@nightbrd commented on GitHub (Oct 18, 2024):
Hey there, I'm currently also having the same problem, but I'm running it through Docker on Windows, so I'm not sure how to go on about this, as I'm also not as savvy as some people, or it's simply me getting limited by Windows. This problem only started in version 0.8.5rc43.
@pirate commented on GitHub (Oct 18, 2024):
Maybe windows drives are simply incompatible with Unix socket files?
I can do some research.
Sorry I don't really know anything about windows.
@kdkd commented on GitHub (Oct 18, 2024):
If it helps, the same is occurring on unraid's docker, if you tell it to pull the dev branch instead of the last release.
@kdkd commented on GitHub (Oct 18, 2024):
The issue seems to be that create_worker_config() is being called AFTER supervisord is being started up, so supervisord is erroring out because it can't find the workers directory.
start_server_workers calls get_or_create_supervisord_process which deletes the workers directory if it already exists, then immediately starts up supervisord which isn't happy, because it's trying to include "/data/tmp/c42fa52e/workers/*.conf". The workers directory and the files in it are only being created after supervisord is started. This was possibly working before because the directory and its contents were already there from a previous startup.
Somehow create_worker_config for all the workers needs to be called before get_or_create_supervisord_process in start_server_workers, and the cleanup of the stale workers directory needs to happen before both of these things.
@pirate commented on GitHub (Oct 18, 2024):
Nah that warning is a red herring. The workers dir does not need to exist before it's started.
create_worker_config is supposed to come after supervisors starts. Because we need to confirm it will start it in a stable state without workers before we start adding them.
The worker dir is auto created lazily whenever a worker is created that depends on it.
I will hide those errors at some point, or create a dir to silence them, but for now it's not as important as the permissions error that happens when supervisord tries to create the socket. Can you share the most recent last bit in data/logs/supervisord.log
@Mika- commented on GitHub (Oct 19, 2024):
I'm also running docker on Unraid and got the same problem.
supervisord.log says it starts:
Docker on Unraid and Windows uses remote filesystem so nfs propably can't handle socket files.
@pirate commented on GitHub (Oct 19, 2024):
I can easily fix it by falling back the socket location to being inside /tmp in the container.
It's a shame though, I was hoping we could keep the socket in the bind mount, but I guess it doesn't work with too many systems / remote filesystems.
@pirate commented on GitHub (Oct 21, 2024):
Should be fixed in
a211461fCan you give
:deva try?@Mika- commented on GitHub (Oct 21, 2024):
Fix confirmed as working