this post was submitted on 16 Mar 2024
29 points (87.2% liked)

Piracy: ꜱᴀɪʟ ᴛʜᴇ ʜɪɢʜ ꜱᴇᴀꜱ

54083 readers
319 users here now

⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.

Rules • Full Version

1. Posts must be related to the discussion of digital piracy

2. Don't request invites, trade, sell, or self-promote

3. Don't request or link to specific pirated titles, including DMs

4. Don't submit low-quality posts, be entitled, or harass others



Loot, Pillage, & Plunder


💰 Please help cover server costs.

Ko-FiLiberapay


founded 1 year ago
MODERATORS
 

Setup:

Debian running podman. Containers and compose files are managed with Dockge. qBit and Gluetun are on a single compose file and all qBit traffic is routed through Gluetun.

qBit seems to starts first before Gluetun is fully set up and qBit doesn't see the open port. Every time I start them together, I have to manually restart qBit again once Gluetun is ready. Once it's restarted, it shows as open and connected again.

I tried looking for ways to delay startup in a compose file but I didn't get any results.

Is there a solution to this?

https://pastebin.com/kgqt8aJ7

top 14 comments
sorted by: hot top controversial new old
[–] [email protected] 9 points 6 months ago (2 children)

Did you specify a dependency? https://docs.docker.com/compose/compose-file/05-services/#depends_on

If qbit depends on gluetun it doesn't start before it.

For this kind of question it's always good to show the compose file(s)

[–] jws_shadotak 1 points 6 months ago (1 children)

I added this to my qBit section:

    depends_on:
      gluetun:
        condition: service_healthy
        restart: true

It caused an error with gluetun somehow

[–] [email protected] 1 points 6 months ago (1 children)

You only need depends_on: gluetun. Did you observe the logs at boot? Do they still show that qbit starts first?

[–] jws_shadotak 1 points 6 months ago

qBit starts second but Gluetun isn't finished and doesn't open the port for another few seconds, causing this problem

[–] jws_shadotak 1 points 6 months ago (1 children)

I added a pastebin of the compose file

I tried adding depends_on to the qBit, but I got the same result. I think it's already dependent on gluetun for the network_mode

[–] [email protected] 2 points 6 months ago (1 children)

See if your qBit container supports mounting scripts to be run at startup and just throw in a sleep 60 or whatever

[–] jws_shadotak 1 points 6 months ago

I don't see support for it in the Linuxserver documents

[–] HumanPerson 1 points 6 months ago (1 children)

I have had a similar issue I think. Try killing and removing the containers (docker kill and docker RM) and then start it. Iirc that was what fixed it for me.

[–] jws_shadotak 1 points 6 months ago

This happens every time I start them together, though. This is just a temporary fix

[–] [email protected] 1 points 6 months ago* (last edited 6 months ago) (1 children)

I use only the default depends_on along with network mode in my setup and it works but your glutun might be taking longer to load so something like this might help.

You definitely need some kind of depends on thought:

https://docs.docker.com/compose/startup-order/

[–] jws_shadotak 1 points 6 months ago

I added this to my qBit section:

    depends_on:
      gluetun:
        condition: service_healthy
        restart: true

It caused an error with gluetun somehow

[–] [email protected] 1 points 6 months ago (1 children)

Why do you think it's firewalled?

Does the web gui work, and just the torrents are failing?

I assume you didn't forget to open the port on the machine. I made that mistake and it took forever to figure out

[–] jws_shadotak 1 points 6 months ago

Torrents are stalling and it's only seeding about 600 KB/s. The icon at the bottom shows a little flame and the hover text says "firewalled".

Restarting qBit through the Dockge web terminal turns that flame icon into a globe and it starts finding hundreds of DHT networks. Uploads nearly max out my upload bandwidth.