-
-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Binding WebUI to non-localhost prevents s6-notifyoncheck from announcing readiness (thus cannot catch termination signal) #332
Comments
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid. |
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? |
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. |
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. |
Appreciate that, thanks. If implementing this is not reasonable, please at least document this behaviour in the README.
Whoops. Guess I'll never be using Swarm then :) I edited |
Can you test #333 when it finishes building and see if it fixes your issue. |
Is there an existing issue for this?
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
ordocker stop
, it will do nothing until the defaultstop_grace_period
is reached, and the container is killed.Maybe related issues: #321 (probably not), #196
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:
When asking the container to stop, under that you will see:
Along with, in qBittorrent's log:
qBittorrent exits safely.
Steps To Reproduce
connection to...
and[ls.io-init] done.
messages.I THINK this occurs due to the following command in the s6 initialisation thing:
docker-qbittorrent/root/etc/s6-overlay/s6-rc.d/svc-qbittorrent/run
Lines 9 to 11 in 4437b92
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):
qBittorrent.conf
for theWebUI\Address=<address>
line. Additionally, use the port specified in that file, too.logs/qbittorrent.log
for theWebUI: Now listening on IP: <address or *>, port: <port>
line.netstat -nlt
for a local address that matches the port defined in envWEBUI_PORT
.WEBUI_ADDRESS
).Environment
CPU architecture
x86-64
Docker creation
Container logs
The text was updated successfully, but these errors were encountered: