[BUG] Binding WebUI to non-localhost prevents s6-notifyoncheck from announcing readiness (thus cannot catch termination signal)

FibreTTP commented 1 month ago

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior

...or something like that. I don't understand s6 in the slightest.

When starting the container, qBittorrent starts normally, but when attempting to docker compose down or docker stop, it will do nothing until the default stop_grace_period is reached, and the container is killed.

Expected Behavior

On an configuration where the WebUI is bound to all addresses, when the container starts up, you will see the following sequence of logs:

To control qBittorrent, access the WebUI at: http://localhost:53411/
Connection to localhost (::1) 53411 port [tcp/*] succeeded!
[ls.io-init] done.

When asking the container to stop, under that you will see:

Catching signal: SIGTERM
Exiting cleanly

Along with, in qBittorrent's log:

qBittorrent termination initiated
BitTorrent session successfully finished.
Saving resume data completed.
qBittorrent is now ready to exit

qBittorrent exits safely.

Steps To Reproduce

Set qBittorrent WebUI IP to a non-localhost address.
Stop the container.
The qBittorrent container and qBittorrent itself will never output any messages regarding exiting, and will be killed after the grace period.
When starting the container again, the qBittorrent container will never output the connection to... and [ls.io-init] done. messages.

I THINK this occurs due to the following command in the s6 initialisation thing:

https://github.com/linuxserver/docker-qbittorrent/blob/4437b92c16f7435514653415a25082f2dcc2f902/root/etc/s6-overlay/s6-rc.d/svc-qbittorrent/run#L9-L11

where I think nc is explicitly listening for something to appear on localhost, and if qBittorrent does bind to localhost on the expected port, the init script completes. Its completion is what allows the rest of the s6 whatever to do whatever it needs to be able to pass SIGTERM to qBittorrent, or something.

I can think of a number of ways to fix this (none of which I know how to implement):

Parse qBittorrent.conf for the WebUI\Address=<address> line. Additionally, use the port specified in that file, too.
Parse logs/qbittorrent.log for the WebUI: Now listening on IP: <address or *>, port: <port> line.
Parse netstat -nlt for a local address that matches the port defined in env WEBUI_PORT.
Add an optional environment variable (e.g., WEBUI_ADDRESS).

Environment

- OS: Debian 12 LXC in Proxmox.
- How docker service was installed: Docker official apt sources added to apt.

CPU architecture

x86-64

Docker creation

# docker compose up -d

name: qbittorrent
services:
  qbittorrent:
    image: ghcr.io/linuxserver/qbittorrent:5.0.0-libtorrentv1
    network_mode: container:gluetun-gluetun-1
    restart: unless-stopped
    environment:
      - PUID=3101
      - PGID=3100
      - UMASK=007
      - WEBUI_PORT=53411
      # - DOCKER_MODS=linuxserver/mods:universal-stdout-logs
      # - LOGS_TO_STDOUT=/config/qBittorrent/logs/qbittorrent.log
    volumes:
      - /mnt/ssd-sam-001/config/lxc-dockerapps/qbittorrent/config:/config
      - /mnt/ssd-sam-001/config/lxc-dockerapps/qbittorrent/KEEP_EMPTY:/downloads
      - /mnt/hdd-plm-001/media/torrents:/media/torrents
    # stop_grace_period: 1m

Container logs

*** Notice how the following logs do not show the "connection successful" and "catching signal" messages. ***

[migrations] started
[migrations] no migrations found
usermod: no changes
───────────────────────────────────────

      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   Brought to you by linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    3101
User GID:    3100
───────────────────────────────────────
Linuxserver.io version: release-5.0.0_v1.2.19-ls48
Build-date: 2024-09-30T03:16:32+00:00
───────────────────────────────────────

[custom-init] No custom files found, skipping...
WebUI will be started shortly after internal preparations. Please wait...

******** Information ********
To control qBittorrent, access the WebUI at: http://10.79.252.1:53411

github-actions[bot] commented 1 month ago

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

thespad commented 1 month ago

I'm not entirely sure I want to know the answer to this but I'm going to ask it anyway: why are you trying to bind your webui to an interface address that add far as I can tell isn't accessible from the host?

FibreTTP commented 1 month ago

Why wouldn't it be accesible to the host?

My usecase is simply that I don't want the WebUI to be accesible on the VPN address. I can't set it to localhost as my reverse proxy wouldn't be able to access it. I instead bind it explicitly to the VPN container (Gluetun's) bridge network address, which my reverse proxy is in so it can access services running on Gluetun's network mode. And yeah, I know Gluetun has a firewall, but better to be safe.

Other usecases are just as niche, like running it on the host's network mode on Docker on a VPS with a directly connected WAN interface, and not wanting the WebUI to be accessible to the internet. It cannot be bound to localhost since you would be accessing the VPS over a VPN, and the VPN interface would not be able to reach the loopback device.

thespad commented 1 month ago

Why wouldn't it be accesible to the host?

Because Docker reserves 10.0.0.0/8 for Swarm overlay networks so to get a bridge network with addresses in that range you really have to work at it.

I'll have a look at the options for handling this; working with the config file is a nightmare but likely the least problematic approach.

FibreTTP commented 1 month ago

Appreciate that, thanks. If implementing this is not reasonable, please at least document this behaviour in the README.

Docker reserves 10.0.0.0/8 for Swarm overlay networks

Whoops. Guess I'll never be using Swarm then :)

I edited daemon.json to make 10.64.0.0/12 the default address pool for created networks.

thespad commented 1 month ago

Can you test https://github.com/linuxserver/docker-qbittorrent/pull/333 when it finishes building and see if it fixes your issue.

linuxserver / docker-qbittorrent