Open accforgithubtest opened 7 months ago
Another example - for sqlpage, which runs a few sql's and takes about 20-25 seconds to load because of multiple SQL. In this case, CN is hitting the application with so many requests, that MySQL connection pool is getting exhausted.
This is where some controls around the application behaviour might help.
Regarding your first post: This looks like a misconfigured network / proxyHost
value to me. Please ensure you can ping / curl the domain filebrowser
or dozzle
from inside the container nursery container.
Regarding your second post: This seems a bit like an application issue to me... ContainerNursery tries to generate as little load as possible for the target service by using HEAD
requests (per default). If an application can be crashed by simply requesting it a few times per second, it might just be a badly configured / coded application (for example, missing / wrong limit on connections / threads which is set to same as db connection pool size).
That being said I agree with your point that there might be value in adding an option to configure how often ContainerNursery retries the page.
Do you have time to create a pull request for this? If not, I can take a look at this some time but I can't give you a timeframe.
Hi !, thanks for your reply.
The ping logs from within the CN container shows that it is able to reach the filebrowser container without any issues.
Apologies If I dont understand this correctly, can you please help me understand what / how network configuration can be an issue here, because as soon as I restart the container, I am able to reach the applications via the url. Also the CN config file directly uses the container name, there is no other network specific configuration (apart from pi-hole that points the local dns - which I am sure is working fine as there are other applications that CN works with perfectly fine like handbrake, MkDocs, etc).
- domain:
- files.local.host
containerName:
- filebrowser
proxyHost: filebrowser
proxyPort: 80
timeoutSeconds: 1800
proxyUseCustomMethod: GET
The ping logs from within the CN container shows that it is able to reach the filebrowser container.
/usr/src/app # ping files.local.host
PING files.local.host (192.168.100.25): 56 data bytes
64 bytes from 192.168.100.25: seq=0 ttl=64 time=0.050 ms
64 bytes from 192.168.100.25: seq=1 ttl=64 time=0.146 ms
64 bytes from 192.168.100.25: seq=2 ttl=64 time=0.144 ms
64 bytes from 192.168.100.25: seq=3 ttl=64 time=0.142 ms
64 bytes from 192.168.100.25: seq=4 ttl=64 time=0.146 ms
64 bytes from 192.168.100.25: seq=5 ttl=64 time=0.146 ms
64 bytes from 192.168.100.25: seq=6 ttl=64 time=0.145 ms
64 bytes from 192.168.100.25: seq=7 ttl=64 time=0.064 ms
^C
--- files.local.host ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 0.050/0.122/0.146 ms
/usr/src/app #
Since you ping'ed files.local.host
and not filebrowser
you should probably set proxyHost
to files.local.host
, or alternatively check if pinging using filebrowser
also works (which it should, if both containers are in the same docker network).
If pinging works please also try curl
ing http://filebrowser:80
from the ContainerNursery container.
Thanks for the reply @ItsEcholot .
So, while the web browser is still stuck on the "waking up files" page, I ran the curl command from within CN container and getting the response from filebrowser (looks to be the html for the page file browser UI).
/usr/src/app # curl http://filebrowser:80
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta
name="viewport"
content="width=device-width, initial-scale=1, user-scalable=no"
/>
<title>
File Browser
</title>
<link
rel="icon"
type="image/png"
sizes="32x32"
href="/static/img/icons/favicon-32x32.png"
/>
.......... (lots more html)
So it looks like even though the filebrowser container is up and ping / curl commands are responding correctly, the UI is still stuck in the "Waking up" page.
Does CN need additional configurations for -
Because, looks like CN is basically Getting into a infinite requests loop situation for certain applications, and this is happening indefinitely until CN container is restarted manually. And because I have a pi-hole in my setup, the pihole container is seeing crazy amounts of traffic from CN.
I have also tried using the
proxyUseCustomMethod: GET
, and it doesn't seem to help.When manually looking at the docker logs for these applications, they are all starting up fine. Some start up really fast (Dozzle, FileBrowser) and some of them are slightly slower (code-server, homeAssistant), but even these are only a matter of about 3-8 seconds on a desktop.
In all these cases, I do not understand why CN is not able to recognize the container is up, because as soon as I restart CN the request for all of them is going thru successfully.
The issue seems to be when CN is starting the container. If the container is already running (i.e when CN is restarted), there is no issue it seems.
Applications I have seen this issue with - FileBrowser, dozzle, codeserver (vscode), n8n, HomeAssistant, etc (probably many more that I havent come across).
Debug Logs for File Browser -
Debug Logs for dozzle -
I also have few other containers where I do not see this issue. For example, MkDocs is another container I have which does take over 5 seconds to start up, however CN handles it well without any issues. Its only certain containers above that have this issue.