Arr containers launching before qbittorrent is ready and causing errors

General
1

So for some reason whenever I startup my stack containing the docker compose with qbittorrent, qbit manage and the arr apps I get errors from qbit manage and the arr apps basically saying they couldn’t connect to qbittorrent. But then after a little bit that qbit manage connects just fine but the arr apps all have to be manually restarted to get them to connect to qbittorrent.

My thinking is that maybe the containers for qbit manage and the arr apps are attempting to connect to qbittorrent before it’s container has finished starting up? But idk how to fix that. I tried using a healthcheck in my docker compose

      healthcheck:
           test: curl --fail http://localhost:8282/api/v2/app/version || exit 1
           interval: 30s
           timeout: 10s
           retries: 5
           start_period: 15s # Wait for qBittorrent to start up initially

followed by adding this to the arr apps and qbit manage

   depends_on:
      qbittorrent:
        condition: service_healthy

But that didn’t really help much. The first time I restarted the docker stack after adding that health check it seemed to work. But then later in the day I redeployed the stack and the errors came back again even though the qbit manage and arr containers shouldn’t have started up until qbittorrent was ready.

So I’m wondering how I would go about fixing it?

2

Take a look at this link.

3

Thanks for the reply. I did try a healthcheck and depends_on condition before. But I looked more into it after seeing that link and discovered that supposedly when using something like Komodo Docker Manager’s Stacks to create a docker compose file it doesn’t properly support the depends_on conditions.

So I just copied my compose.yaml from Komodo over to the host machine. Then mounted the location of the compose.yaml on the host machine to a location that Komodo can still access because I still wanted to try and manage all my containers from Komodo. So then rather than creating a compose file for a stack right in Komodo I created a stack and for the “Choose Mode” option I chose File on Server rather than UI defined. Then just pointed Komodo to the compose.yaml file on the host machine. Then when I deployed the existing compose file via Komodo it seemed to work and deploy properly with the healthchecks working.

I tested deploying and then redeploying and both times my arr apps seemed to launch without the errors about connecting to qbittorrent! So hopefully that has solved the issue.

Thanks!

4

Nevermind. Just restarted the host machine and the same issue occurred when all the docker containers started back up. Here is a screenshot of the error and the healtcheck/depends_on

So I’m not sure why it didn’t work. Unless there is a better healthcheck to use?

5

Not sure about the original incosistency of the depends on feature when using docker compose comands, but it is a compose feature, so when you restart the machine, there is nothing to handle the dependencies at boot. If the restart policy is “always”, the container should restart when it fails and the dependency could start in the meantime. So the depends_on in compose is good to avoid unnecessary restarts during development (when it works correctly), but I would still make sure that the failing container restarts until the dependency is ready. We had reports related to restart poolicy issues when restarting the host machine, which I have not reproduced for a long tiime, but to be safe, you could also change the entrypoint of a container with dependencies, in which entrypoint you could run some test commands in a loop and start the main process only after the dependencies are running.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.