Mod fails to initialize due to slow CURL

[Sirs0ri]

Hi!

Problem Description:

I recently noticed that some of my containers that should be part of my tailnet aren't, and after some investigating I found that the CURL command to download Tailscale times out after 10 minutes, and the installation of tailscale subsequently fails. I hope this is the right place to report this issue, if not I'd appreciate a pointer in the right direction!

Steps to reproduce:

The simplified version: run the curl command and a wget equivalent in a local terminal, and observe how much slower curl is:

$ curl https://pkgs.tailscale.com/stable/tailscale_1.74.1_arm64.tgz -o tailscale.tgz
$ wget https://pkgs.tailscale.com/stable/tailscale_1.74.1_arm64.tgz -O tailscale.tgz

The full repro: Run a basic nginx server through docker compose:

services:
  ts-timeout:
    image: linuxserver/nginx:latest
    environment:
      - DOCKER_MODS=ghcr.io/tailscale-dev/docker-mod:main
      - TAILSCALE_STATE_DIR=/var/lib/tailscale
      - TAILSCALE_HOSTNAME=ts-timeout
      - TAILSCALE_AUTHKEY=tskey-auth-your-key-here
    volumes:
      - ts_timeout:/var/lib/tailscale
    ports:
      - "8083:80" # use any free port here

volumes:
  ts_timeout:

Run the whole thing using docker compose up. You should see something like this:

$ docker compose up ts-timeout

(... trimmed for brevity)

ts-timeout-1  | [pkg-install-init] **** Installing all mod packages ****
ts-timeout-1  | fetch http://dl-cdn.alpinelinux.org/alpine/v3.20/main/aarch64/APKINDEX.tar.gz
ts-timeout-1  | fetch http://dl-cdn.alpinelinux.org/alpine/v3.20/community/aarch64/APKINDEX.tar.gz
ts-timeout-1  | (1/4) Installing libmnl (1.0.5-r2)
ts-timeout-1  | (2/4) Installing libnftnl (1.2.6-r0)
ts-timeout-1  | (3/4) Installing libxtables (1.8.10-r3)
ts-timeout-1  | (4/4) Installing iptables (1.8.10-r3)
ts-timeout-1  | Executing busybox-1.36.1-r29.trigger
ts-timeout-1  | OK: 167 MiB in 191 packages
ts-timeout-1  | /run/s6-rc:s6-rc-init:BALEpN/servicedirs/s6rc-oneshot-runner /run/s6-rc:s6-rc-init:BALEpN/servicedirs/s6rc-oneshot-runner
ts-timeout-1  |   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
ts-timeout-1  |                                  Dload  Upload   Total   Spent    Left  Speed
100  3308  100  3308    0     0   2910      0  0:00:01  0:00:01 --:--:--  2914
ts-timeout-1  |   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
ts-timeout-1  |                                  Dload  Upload   Total   Spent    Left  Speed

(...nothing happens for a long time...)

ts-timeout-1  | curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
ts-timeout-1  | s6-rc: warning: unable to start service init-mod-universal-tailscale-postinstall: command exited 92

The first request gets the current version and finishes quickly, the second one is the one to download the tarball, and it'll fail after 10 minutes.

Running the install script manually works (but that doesn't help much since I'd have to manually run it every time the container restarts).

[bastelbert]

I've got the same issue with my Jellyfin container:

/run/s6-rc:s6-rc-init:eceOAB/servicedirs/s6rc-oneshot-runner /run/s6-rc:s6-rc-init:eceOAB/servicedirs/s6rc-oneshot-runner % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3308 100 3308 0 0 7792 0 --:--:-- --:--:-- --:--:-- 7783 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 21 27.6M 21 6128k 0 docker inspect -f '{{ index .Config.Labels "build_version" }}' lscr.io/linuxserver/jellyfin:latest 42 27.6M 42 11.6M 0 0 29618 0 0:16:17 0:06:52 0:09:25 35780 62 27.6M 62 17.2M 0 0 29748 0 0:16:13 0:10:07 0:06:06 28662 curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2) s6-rc: warning: unable to start service init-mod-universal-tailscale-postinstall: command exited 92

linuxserver/docker-jellyfin#271

[pandalanax]

seems to be working again...

should it happen again, these changes were necessary:

pandalanax@3cfb40f

fork and run from your own package registry

[bastelbert]

Unfortunately, it only worked for me for a short time. Last night my container was restarted during a backup, now the curl call is not working again.

[h3xp]

same issue here

[pandalanax]

after #29, i changed to using a sidecar container after always having issues. way more stable and probably the preferred way now.