1

I use following docker-compose.yml for my copyright troll protection. Without going into much details it has 1 container named pia_gluetun that serves as a vpn connection of other containers. Another container is called pia_deluge, and it along with all the rest of containers depends on pia_gluetun.

So far so good. Now all the other containers have various depends_on settings in order to ensure the network + data source containers start before the media server containers.

However last 3 reboots I ended up with all of the containers started (presumably in correct order as they all work with no warning of missing services), apart form the pia_deluge one which ends up stopped, with no logs - indicating it for w/e reason didn't even bother trying to start (i think?). Subsequently starting it works perfectly ok.

version: '3.7'
services:
  gluetun:
    image: qmcgaw/private-internet-access
    container_name: pia_gluetun
    cap_add:
      - NET_ADMIN
    network_mode: bridge
    ports:
      - 8888:8888/tcp # HTTP proxy
      - 8388:8388/tcp # Shadowsocks
      - 8388:8388/udp # Shadowsocks
      - 8000:8000/tcp # Built-in HTTP control server
# other containers ports
      - 8112:8112     # deluge webui
      - 58846:58846   # deluge daemon
      - 6767:6767     # bazarr
      - 8989:8989     # sonarr
      - 7878:7878     # radarr
      - 8686:8686     # lidarr
      - 9117:9117     # jackett
      - 8191:8191     # flaresolverr
      - 4040:4040     # airsonic
      - 8096:8096     # jellyfin
      - 8227:8227     # pyload
    volumes:
      - ./data_gluetun:/gluetun
      - ./data_gluetun/port_forward:/tmp/gluetun/forwarded_port
    environment:
      - VPNSP=private internet access
      - TZ=${TIMEZONE}
      - USER=${PIA_USER}
      - PASSWORD=${PIA_PASS}
      - REGION=${PIA_REGION}
      - PORT_FORWARDING=on
      - FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24
      - HTTPPROXY=on
#      - HTTPPROXY_USER=${PROXY_USER}
#      - HTTPPROXY_PASSWORD=${PROXY_PASS}
      - SHADOWSOCKS=on
      - SHADOWSOCKS_PASSWORD=${SHADOW_PASS}
    restart: unless-stopped

  pyload:
    image: linuxserver/pyload
    container_name: pia_pyload
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TIMEZONE}
    volumes:
      - ./config_pyload:/config
      - /shares/_Download:/downloads
    network_mode: "service:gluetun"
    restart: unless-stopped
    depends_on:
      - gluetun

  deluge:
#    image: linuxserver/deluge
    build: ./deluge_my_image
    container_name: pia_deluge
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TIMEZONE}
      - DELUGE_LOGLEVEL=INFO #optional
    volumes:
      - ./config_deluge:/config
      - /shares/media/_downloads:/downloads
#      - /shares/media:/media
    network_mode: "service:gluetun"
    restart: unless-stopped
    depends_on:
      - gluetun

  jackett:
    image: linuxserver/jackett
    container_name: pia_jackett
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TIMEZONE}
    volumes:
      - ./config_jackett:/config
      - /shares/media/_downloads:/downloads
    network_mode: "service:gluetun"
    restart: unless-stopped
    depends_on:
      - gluetun
      - flaresolverr

  flaresolverr:
    container_name: pia_flaresolverr
    image: 'ghcr.io/flaresolverr/flaresolverr:latest'
    environment:
      - LOG_LEVEL=info
    network_mode: "service:gluetun"
    restart: unless-stopped
    depends_on:
      - gluetun

  lidarr:
    image: linuxserver/lidarr
    container_name: pia_lidarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TIMEZONE}
    volumes:
      - ./config_lidarr:/config
      - /shares/media:/media
    network_mode: "service:gluetun"
    restart: unless-stopped
    depends_on:
      - gluetun
      - jackett
      - deluge

  radarr:
    image: linuxserver/radarr
    container_name: pia_radarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TIMEZONE}
    volumes:
      - ./config_radarr:/config
      - /shares/media:/media
    network_mode: "service:gluetun"
    restart: unless-stopped
    depends_on:
      - gluetun
      - jackett
      - deluge

  sonarr:
    image: linuxserver/sonarr:preview
    container_name: pia_sonarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TIMEZONE}
    volumes:
      - ./config_sonarr:/config
      - /shares/media:/media
    network_mode: "service:gluetun"
    restart: unless-stopped
    depends_on:
      - gluetun
      - jackett
      - deluge

  bazarr:
    image: linuxserver/bazarr
    container_name: pia_bazarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TIMEZONE}
    volumes:
      - ./config_bazarr:/config
      - /shares/media:/media
    network_mode: "service:gluetun"
    restart: unless-stopped
    depends_on:
      - gluetun
      - sonarr
      - radarr

  airsonic:
    image: airsonicadvanced/airsonic-advanced:latest
    container_name: pia_airsonic
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TIMEZONE}
      - 'JAVA_OPTS=-Xmx1024m -Xms1024m'
    volumes:
      - ./config_airsonic:/var/airsonic
      - /shares/media/music:/var/music
      - ./playlists_airsonic:/var/playlists
      - ./podcasts_airsonic:/var/podcast
    network_mode: "service:gluetun"
    restart: unless-stopped
    depends_on:
      - gluetun

  jellyfin:
    image: linuxserver/jellyfin
    container_name: pia_jellyfin
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TIMEZONE}
    volumes:
      - ./library_jellyfin:/config
      - /shares/media:/media
      - /shares/Dokumenty:/mnt/Dokumenty
#    devices:
#      - /dev/dri/renderD128:/dev/dri/renderD128
#    network_mode: "host"
    network_mode: "service:gluetun"
    restart: unless-stopped
    depends_on:
      - gluetun

In my (admittedly shallow) understanding of the matter if the pia_deluge container doesn't start, shouldn't that prevent sonarr, radarr, lidarr from starting as well?

How can I adjust my docker-compose.yml to ensure desired start order? I previously tried having the vpn container as separate container outside the stack, which messed up with tho containers routed through it something fierce everytime I recreated it.

Many thanks for any insights!

C.G.B. Spender
  • 155
  • 1
  • 9
  • 2
    `depends_on:` only affects the order in which the services start starting. If `deluge` tries to connect to something via the `gluetun` process, the container is guaranteed to exist but the tunnel process isn't guaranteed to be fully set up and running. [Docker Compose wait for container X before starting Y](https://stackoverflow.com/questions/31746182/docker-compose-wait-for-container-x-before-starting-y) discusses this in more detail, though in the more common context of waiting for a database or message-broker container with the default networking setup. – David Maze Jan 18 '21 at 16:36
  • @DavidMaze that looks like I'll be able to adapt it to my needs, I will probably switch to restart on failure + healthcheck on the relevant container(s) in order to ensure they start first. Thanks! – C.G.B. Spender Jan 18 '21 at 16:46
  • Haven't rly had time to play with it yet as we're quite busy at work, but what I find strange is this behaviour where the deluge container ends up stopped only happened on reboot (presumably it would happen on `sysctl stop docker` too), but I can't test either atm on account of other services running on the server. However if I do `docker-compose down && docker-compose up` all containers from the stack in question start correctly. How is that different to what happens on reboot then ? – C.G.B. Spender Jan 19 '21 at 14:25
  • Ok, there is definitely something else going on. Managed to find time to reboot the server few times in a row and it's not always the deluge container, nor does it always happen. Moreover, when it happens, it's not like the container tried to start, couldn't connect to internet and then died; the container remains stopped from the reboot and does not even attempt to start as no logs from after the reboot are produced. However last 2 reboots all containers started no problem. – C.G.B. Spender Jan 21 '21 at 15:54
  • Was there ever a solution to this? I experience exactly the same issue where I need to run `docker-compose down && docker-compose up` – roadkill247 Nov 17 '22 at 15:25
  • There is no solution I could find apart from overly complicated and overengineered shell scripts that ping the service endpoint until it is live on the designated port and then it proceeds to start the remaining dependent containers. – C.G.B. Spender Nov 18 '22 at 20:05

1 Answers1

0

I am the great post necromancer and the solution is having properly implemented healthcheck and then expanding the depends_on to depend on service_healthy not service_started. Having the containers in the stack set up like that it's then easy to interlink them like below and when rebuilding the stack the container will wait to start until the container it depends on is healthy as I wanted 2 years ago:

  sonarr:
    image: lscr.io/linuxserver/sonarr
    container_name: sonarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TIMEZONE}
      - DOCKER_MODS=ghcr.io/gilbn/theme.park:sonarr
      - TP_THEME=nord
    volumes:
      - ./config_sonarr:/config
      - /shares/nfs/torrents:/torrents
      - /shares/samba/media:/media
      - /shares/samba/media2:/media2
    ports:
      - 8989:8989
    restart: always
    depends_on:
      prowlarr:
        condition: service_healthy
      qbittorrent:
        condition: service_healthy
    stop_grace_period: 60s
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8989"]
      interval: 30s
      timeout: 10s
      retries: 5
C.G.B. Spender
  • 155
  • 1
  • 9