Open conrad82 opened 3 years ago
Someone else has been getting this error, but it's not related to pandoc because we removed that dependency. I'll look into it :)
Wow quick response! :) I could find the error message around the web, but a bit unclear to me how it relates to this project
Congrats on v1.0 :)
@conrad82 Can you post your full docker logs archivy
?
More information to debug with can't hurt.
@Jafner , the log is not very exciting I'm afraid: (I assume multiple lines is caused by restart: unless-stopped )
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
...
Tested with FLASK_DEBUG=1 also, just in case. No difference.
I tried building it myself (I forked archivy-docker repo to https://github.com/conrad82/archivy-docker )
First it fails at step 3
Step 3/18 : RUN pip3.9 install --prefix=/install archivy==$VERSION
---> Running in 6cd98dfb29af
ERROR: Could not find a version that satisfies the requirement archivy==
ERROR: No matching distribution found for archivy==
ERROR: Service 'archivy' failed to build: The command '/bin/sh -c pip3.9 install --prefix=/install archivy==$VERSION' returned a non-zero code: 1
I simplified the install command to pip3 install archivy
It then fails at brotli installation, from the error messages I suspect due to missing gcc
Added steps for installing gcc and g++ - brotli succeeds!
After some more tweaking, I got it to start with the following changes to the code! : https://github.com/archivy/archivy-docker/compare/main...conrad82:main?diff=unified The code is a bit hacky, so I wasn't planning a pull request. Also, the modifications are quite small.
Now the logs look like this:
$ sudo docker logs archivy
Setting environment variables.
The following environment variables were set:
FLASK_DEBUG=1
ELASTICSEARCH_ENABLED=1
ELASTICSEARCH_URL=http://elasticsearch:9200/
ARCHIVY_PORT=5000
Checking if Elasticsearch is up and running
Elasticsearch is running @ http://elasticsearch:9200/.
Starting Archivy
Running archivy...
[2021-02-05 12:06:52,148] INFO in __init__: OUTPUT_FOLDER: /tmp/click-web
* Serving Flask app "archivy" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: on
* Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
* Restarting with stat
Running archivy...
[2021-02-05 12:06:56,087] INFO in __init__: OUTPUT_FOLDER: /tmp/click-web
* Debugger is active!
* Debugger PIN: 326-819-398
I don't get the web page up through my reverse proxy though,... I'll have to take a look another time..
Raspberry Pi has arm
architecture. Ans in this case, Rpiv4 has aarch64
. amd64
builds of docker containers cannot run on aarch64
. Ideally, arm buillds should be pushed to hub.docker.com instead and users should be able to pull the docker containers for the respective architecture like archivy-armhf
or archivy-aarch64
depending on the architecture. So, currently, there is no way to use archivy's docker image on an arm arch device like Rpi4 or on Android. The only solution is to build from source.
And also, I took a look at https://github.com/archivy/archivy-docker/compare/main...conrad82:main?diff=unified. At one end, the base image should be arm32v7/python
or arm32v6/python
and not python:3.9-alpine
for optimal performance.
Ping - It's been a couple months since this issue was last discussed. Any chance it can get some attention?
Ping - It's been a couple months since this issue was last discussed. Any chance it can get some attention?
Thanks for the reminder. I'm gonna do some testing and dev this weekend. I'll keep this thread up to date on my efforts. It's a simple conversion on paper, but I don't have an arm64 device to test with.
@callingshotgun Have you tried building a copy from the dockerfile in the archivy-docker repository?
It's based on the python:3.9-alpine
tag, which is a multi-architecture tag. I believe our current workflow builds a single amd64 image from the dockerfile before sending it to dockerhub. If you build the image yourself from the dockerfile it should automatically switch to the arm64
version of python:3.9-alpine
during the build process.
Let me know if this works for you. If it does, we can probably add an arm64 build to the workflow.
Thanks @Jafner ! Alas, did not work.
Attached log. Command I tried was
docker build https://github.com/archivy/archivy-docker.git#main --build-arg VERSION=1.1.4
Was that the right version number to use? It seemed to go south trying to add Brotli to the image.
Collecting brotli
Downloading Brotli-1.0.9.zip (510 kB)
WARNING: The candidate selected for download or install is a yanked version: 'validators' candidate (version 0.15.0 at https://files.pythonhosted.org/packages/c4/4a/4f9c892f9a9f08ee5f99c32bbd4297499099c2c5f7eff8c617a57d31a7d8/validators-0.15.0.tar.gz#sha256=31e8bb01b48b48940a021b8a9576b840f98fa06b91762ef921d02cb96d38727a (from https://pypi.org/simple/validators/))
Reason for being yanked: Missing python_requires in setup.py
I want to fix this. Could someone with a raspberry pi join the discord server and ping me so we can troubleshoot it? I'm not sure why but it seems gcc has problems installing on an arm device - either way doing multi-architecture images would be good.
We can probably do something like what's outlined here: https://www.docker.com/blog/multi-arch-images/
I am unable to run archivy through docker-compose on Raspberry Pi 4. It runs fine if I install it directly on the RPi using
pip3 install archivy
I am running ubuntu server 20.10 (64-bit). Since it runs outside docker, I suspect it is related to the Dockerfile, but I am not able to see the cause.
I get the following error in the docker logs:
archivy_1 | standard_init_linux.go:211: exec user process caused "exec format error"
Elasticsearch is running fine. Snippet of my docker-compose.yml file below (I also run other containers not shown. The container is exposed through a Caddy reverse proxy):
Reading a bit in your repository, I see an issues note that it does not work on arm due to pandoc is missing. I am able to install pandoc on ubuntu server on the raspberry pi using apt. Is this issue related to base image being alpine? Not sure if it is related to the error though..