fetch failed under docker container arm64

[hugo-akaora]

Hello,

I have the error fetch failed [2024-09-20T15:48:12.296Z] URL: https://www.wikipedia.org on my docker run command output.

docker run -v $(pwd):/usr/src/app/out singlefile "https://www.wikipedia.org" wikipedia.html

Where as:

root@iv:~# docker run --rm -it --entrypoint sh docker.io/jasongzy/singlefile:latest 
/usr/src/app/node_modules/single-file-cli $ wget https://www.wikipedia.org
Connecting to www.wikipedia.org (185.15.58.224:443)
'index.html' saved

So I know it's not a network related issue.

Any idea how I can diagnose this trouble?

Thank you

[hugo-akaora]

Seems that somebody else reproduced it: sissbruecker/linkding#761

My guess is that single-file-cli does not act the same on arm64.

I'll try without docker to see

[hugo-akaora]

Okay, it works properly with chromium installed natively on Debian Bookworm arm64 and running single-file-cli arm64.

So it's somewhat related to Docker or the upstream image used, zenika/alpine-chrome:with-node

[hugo-akaora]

I tried to use it with a Debian based image and I came accross the same problem:

FROM timbru31/node-chrome:slim

WORKDIR /usr/src/app
RUN npm install --omit=dev single-file-cli
ENTRYPOINT [ \
    "npx", \
    "single-file", \
    "--browser-executable-path", "/usr/bin/chromium", \
    "--output-directory", "./out/", \
    "--dump-content", \
    "https://www.wikipedia.org" ]

root@iv:~# docker run --rm -it docker.io/library/chromium
fetch failed [2024-09-23T15:43:03.040Z] URL: https://www.wikipedia.org

Alas it seems that it's not possible to run single-file-cli under Docker on arm64

Tried the exact same thing on x86_64 and it works great!

[gildas-lormeau]

It's weird, I'm definitely not a Docker specialist but I managed to run on a MacBook Pro M2 and without any error, an image created with the Dockerfile of single-file-cli as is. I ran the command docker buildx build --no-cache --platform linux/arm64 -t singlefile . from the root folder of the repository and docker run singlefile https://example.com to test it.

I checked the “Architecture” field with the command docker image inspect and it's “arm64”, as expected.

[hugo-akaora]

Well, interesting, as the Macbook Pro M2 is infinitely more powerful than my Raspberry Pi 3. I have a Pi 4, I'll try with it!

Are there any tips to diagnose some browser related issues ? Is single-file-cli able to handle browser crashes for instance?

[hugo-akaora]

It works with my Pi 4, so it's not platform related, nor arch related, it's device related.

I'll try with a vanilla install of Debian Bookworm on the Pi 3, my docker setup is a bit customized so maybe it's related.

Thank you for your help!

Feel free to close the issue if you want, I'll reopen it if the issue still occurs with a fresh install.

PS: I'm still interested by some tips how to debug browser output. I tried the flag --browser-debug but it doesn't help.

[gildas-lormeau]

Thanks for the info, I'm even less of a Raspberry Pi specialist than Docker but I was wondering if you've tested “linux/arm/v7” instead of "linux/arm64" for the platform?
Regarding the logs, I need to check if there's a flag for this in Chrome otherwise I might implement this feature. You need actually a display server (e.g. X) to use --browser-debug which is used to open the Dev Tools and add a breakpoint as soon as possible.

[hugo-akaora]

Hello, thank you @gildas-lormeau for you help.

Actually I tested on a freshly installed Debian Bookworm with Docker on Raspberry Pi 3B and it's working properly with jasongzy/singlefile's arm64 image.

So on single-file-cli, everything is working as expected!

(So my ultimate guess is that Chrome does not like my customized Docker setup!)

[hugo-akaora]

Mhhh, I tested a Dockerfile with a X server included :

FROM timbru31/node-chrome:iron-slim

WORKDIR /usr/src/app
RUN npm install --omit=dev single-file-cli

EXPOSE 5900 

ENV HOME /root
ENV TZ Etc/UTC
ENV SHELL /bin/bash
ENV PS1='# '
ENV DEBIAN_FRONTEND=noninteractive
ENV PASSWORD="root"

RUN apt-get update -qq; \
    apt-get upgrade -yqq; \
    apt-get install -yqq tigervnc-standalone-server openbox tint2 pcmanfm xfce4-terminal supervisor procps curl telnet iproute2; \
    apt-get clean
RUN mkdir /root/.vnc; \
    echo $PASSWORD | vncpasswd -f > /root/.vnc/passwd; \
    chmod 600 /root/.vnc/passwd

ADD etc/xdg/pcmanfm /root/.config/pcmanfm
ADD etc /etc

CMD ["/usr/bin/supervisord","-c","/etc/supervisord.conf"]

I was able to use single-file installed via Chrome Web Store:

It's kinda weird it doesn't work via the cli? I tried with --browser-debug=true and no output, the same error as always.

[gildas-lormeau]

Do you confirm you run single-file by executing "npx", "single-file" ... in the Docker file?

[hugo-akaora]

Hello,
Indeed, I use npx single-file --browser-executable-path /usr/bin/chromium --output-directory ./out/ --dump-content https://www.wikipedia.org. Sorry, my screenshot with the terminal is a bit confusing.

[gildas-lormeau]

Actually, I do not understand why the error is saying that single-file or single-file-cli cannot be found. Maybe you are not launching single-file from the correct folder, e.g. the WORKDIR /usr/src/app in my Dockerfile?

[hugo-akaora]

The terminal window in my previous screenshot was not the good one. Actually I ran that command:

[gildas-lormeau]

The problem with this error is that it's very generic. I remember, however, that I've seen this kind of error in the past, when there's not enough space on the disk. I doubt it's the source of the problem though. Note that you can press F12 to open the debugger in Chrome (or use the menu).

Finally, I'm surprised to see the browser in your screenshot, given that by default it's launched in headless mode. Normally, you'd have to pass --browser-debug or --browser-headless to display its window but I do not see one of these options in your command.

[hugo-akaora]

Hello, thank you @gildas-lormeau

Actually the browser window was only intended to prove that using the extension installed in the browser, it's working as intended. Whereas using the command supposed to achieve the same result, it does not work. So the browser in the screenshot is not triggered by the command.

Interestingly, the browser does not appear when using --browser-debug or --browser-headless in the command. Its hard to debug when debugging helper does not work :-D