Echolot Posted September 9, 2021 Share Posted September 9, 2021 (edited) Overview: Puts Docker Containers to sleep and wakes them back up when they're needed. Written in Node.js, this application acts as a HTTP reverse proxy and stops Docker containers which haven't been accessed recently and starts them again when a new request comes in. ContainerNursery also makes sure there are no more active WebSocket connections before stopping the container. To improve the user experience a loading page is presented, which automatically reloads when the containers webserver is ready. The application listens on port 80 by default for HTTP traffic and uses the socket at /var/run/docker.sock to connect to the docker daemon. GitHub: https://github.com/ItsEcholot/ContainerNursery GitHub Packages: https://github.com/ItsEcholot/ContainerNursery/pkgs/container/containernursery Quick Demo: Setup Guide: There are multiple ways to setup and use ContainerNursery depending on your use case and network setup. In this guide I want to give a quick overview which choices have to be made and to present a non exhaustive list of possible solutions for each choice. More information can be found in the README.md file on the GitHub Repo. DNS: Since ContainerNursery is a reverse proxy it will use the host header of the request to decide where the request should be routed to. This means we have to reach CN using a domain name and can't simply use an IP + PORT combination. So you have to find a way to route multiple domain names to the same IP (probably the Unraid IP since CN is running as a Docker Container on that machine). Hosts File: Edit the local hosts file on your device. Your OS uses this file to resolve domain names to IPs. This file is located at /etc/hosts on Linux and MacOS and at C:\Windows\System32\drivers\etc on Windows. Add an entry for each application you want to proxy through ContainerNursery. Example: 192.168.1.2 my-important-app.unraid 192.168.1.2 handbrake.apps.unraid 192.168.1.2 speedtest.apps.unraid In this example 192.168.1.2 is your Unraid (and thus ContainerNursery) IP and the names are freely choosable domains. DNS Server: You can also use your local DNS server to define new domains and point them to your ContainerNursery IP. While more complicated this approach allows all devices which make use of your local DNS server (if you announce it using DHCP, probably all your network devices) to access your apps using the defined domains. Your DNS server could be a PF/OPNSense box, your modem (if it allows adding manual DNS entries) or a dedicated DNS server application like PiHole for example. Since all this sub-methods are configured differently, DuckDuckGo (other search engines are available) is probably the best way to figure this one out by yourself. Ports: By default ContainerNurser is setup, like most reverse proxies, to run on port 80 since this is the default port for HTTP requests. This way you don't have to append a port to the domain name when trying to access your applications. Since port 80 is also used by Unraid to serve it's Webinterface you basically have two options: Change Unraids Webinterface port This is the preferred method since it allows using all your other applications like you would expect them to, i.e without having to append a port to the domain name. This can be accomplished by navigating to the Settings > Management Access page and changing the HTTP port value to something other than 80. 8080 would be a great candidate, since it's easy to remember. This means that from now on you would have to access your Unraid WebUI (only if you don't use https) using the following URL: http://<yourunraidip>:8080 This method also means you could deploy CN using host networking instead of bridge, however I don't recommend this, since the useful isolation layer between host and container is then not used. Change ContainerNurserys port This can be easily done by editing the CN container and making sure you're using bridge networking and maping the port from 80 to 8080 for example. If you use this way the Unraid WebUI will still be available like usual, but all your services have to be accessed with this port appended, for example: http://hanbrake.apps.unraid:8080 Networking: Since you want to use ContainerNursery to proxy your requests to your applications, CN will have to be able to access your other containers. The approach here depends on how your other apps and CNs network is configured. Custom bridge network This is the most elegant solution in my eyes. Custom docker bridge networks allow you to specify which containers should be able to access this network and communicate with each other (without having to map any ports) and most importantly allow you to use the name of the container as a hostname. Docker will then automatically resolve the correct container IP address for you. Using this approach dramatically reduces the attack surface, since less ports are open on the Unraid Host itself. To use this approach open up the Unraid Console using SSH or the WebUI and run the following command, creating a custom bridge network with the name proxy: docker network create proxy Now edit all your applications, which you want to access through ContainerNursery and change the following option: Network Type --> Custom: proxy You can (and should) now remove all port mappings (hint: make a note of what port the app uses inside the container, since they're not always the same), since you will only be accessing the app through the domain (and CN as a reverse proxy) instead of the raw IP + port combination. Make sure ContainerNursery itself is also switched to using your newly created docker bridge network but keep the port mapping (change it to your desired value if needed, see the part about ports above) since we need to be able to access ContainerNursery from other machines so that it can route our requests to the desired containers. Now you can configure ContainerNursery like in this example: proxyHosts: - domain: handbrake.apps.unraid containerName: handbrake proxyHost: handbrake proxyPort: 5800 timeoutSeconds: 14400 Since we use a custom bridge network which translates the container name to the correct IP address we can use handbrake as our proxyHost value. The proxyPort value is the internal port (the port the actual application inside of the container listens on) of the target container since containers of the same bridge network can communicate freely with each other without any port mapping taking place. Default bridge network If you want to use the default bridge network docker provides you will have to map ports on both ContainerNursery and the container you want to access and then use a configuration like in this example: proxyHosts: - domain: handbrake.apps.unraid containerName: handbrake proxyHost: 192.168.1.2 proxyPort: 6800 timeoutSeconds: 14400 192.168.1.2 is the IP of the Unraid machine and the port 6800 is the mapped port of the handbrake container. Host network The same rules as for the default bridge network hold true but now localhost can be used inside the config, since localhost now refers to the Unraid machine and not the CN docker container. proxyHosts: - domain: handbrake.apps.unraid containerName: handbrake proxyHost: 127.0.0.1 proxyPort: 6800 timeoutSeconds: 14400 Edited February 8, 2022 by Echolot Out of Beta 1 Quote Link to comment
Echolot Posted September 9, 2021 Author Share Posted September 9, 2021 (edited) Changelog 30.08.2022 - v1.7.0 Added the ability to proxy traffic to containers using HTTPS, while ignoring their certificate. This is for services which only listen for SSL requests. This does not provide any security over normal http proxying. 08.02.2022 - v1.6.0 Added the ability to add multiple domains that point to the same proxy host. 29.11.2021 - v1.5.2 Fixed a bug where misformed docker event payload would crash ContainerNursery when trying to parse JSON. Thanks to Alfy1080 on the Unraid Forums for the Bug report. 12.10.2021 - v1.5.1 Fixed a bug where the loading page wouldn't be displayed when a path other than `/` is requested. Thanks to @JamesDAdams on GitHub for the Bug report. 29.09.2021 - v1.5.0 Added the ability to stop (and start) multiple containers per proxy host. This is useful if the application supports multiple containers. The first container in the list is the main container, which is used to check if the container is ready and reload the loading page. For usage information check the README.md file on GitHub. 24.09.2021 - v1.4.2 Handle SIGTERM. The ContainerNursery container should now stop (and thus also restart) much quicker. 23.09.2021 - v1.4.1 Fixed an issue where certain editors broke the live config reload functionality by introducing a small delay before reading the config file. 23.09.2021 - v1.4.0 Added stopOnTimeoutIfCpuUsageBelow setting to proxyHosts which prevents ContainerNursery from stoping containers if they're still busy (using more CPU than the limit). For usage information check the README.md file on GitHub. Edited August 30, 2022 by Echolot Update v1.7.0 Quote Link to comment
guillelopez Posted September 18, 2021 Share Posted September 18, 2021 (edited) Would love to see a guide to config this. Seems to need a reverse proxy also? I'm not used to local domain names and not sure how to create them to work with my docker containers. I'm not sure if I need to install something different or use my pfSense system. And does not the container 80 port interfere with the Unraid server 80 port? But seems a great add to the repository, so thanks for your work! Edited September 18, 2021 by guillelopez Quote Link to comment
Echolot Posted September 19, 2021 Author Share Posted September 19, 2021 11 hours ago, guillelopez said: Would love to see a guide to config this. Seems to need a reverse proxy also? I'm not used to local domain names and not sure how to create them to work with my docker containers. I'm not sure if I need to install something different or use my pfSense system. And does not the container 80 port interfere with the Unraid server 80 port? But seems a great add to the repository, so thanks for your work! A guide is definitely something I thought about doing but haven't found the time yet to do, I will try to do it in the course of the next week. A pretty technical "guide" can already be found on the GitHub Project page in the Readme file. If you're using Docker Bridge Network you can map the port 80 easily to something other you prefer. Either way we're working on making the listening port configurable. 1 Quote Link to comment
guillelopez Posted September 19, 2021 Share Posted September 19, 2021 Good news then I managed to configure it so ContainerNursery log said it can detect the other containers, and using the Bridge Network I maped the port to 86 and with the host-ip:86 but still didn't got it working properly, just was able to after 1800s the app turning off the other containers. I think I should try to learn today something about DNS resolvers and this kind of stuff. I access my containers with the ip:port, i'm a simple man 😅 I was following the GitHub Project guide, but get confused with the Domains and NginxProxyManager part, as I not used to it. But as I said, something new to learn. Thanks! Quote Link to comment
guillelopez Posted September 19, 2021 Share Posted September 19, 2021 Well I managed to get it nearly working. I created some host names on my desktop /etc/hosts file. "192.168.1.4 filebrowser.rack" and "192.168.1.4 krusader.rack" I changed the network on your container to custom and used the 192.168.1.4 ip for it. (as I don't want to change Unraid 80 port and can't use ports on /etc/host file, this seemed for me the best solution) and my config.yml is this: proxyHosts: - domain: filebrowser.rack containerName: FileBrowser proxyHost: localhost proxyPort: 87 timeoutSeconds: 1800 - domain: krusader.rack containerName: Krusader proxyHost: localhost proxyPort: 6080 timeoutSeconds: 1800 But I only get an infinite waking up FileBrowser or waking up Krusader. On ContainerNursery logs I get Host not reachable. Tried to change localhost for the unraid ip, and still no luck. Also tried internal containers ips (172.17.0.3 or 172.17.0.8) with their normal ports and also no luck. Quote Link to comment
Echolot Posted September 19, 2021 Author Share Posted September 19, 2021 @guillelopez So just to clarify, the ContainerNursery loading page gets displayed correctly when you visit filebrowser.rack but it just never displays the target application itself? This would mean that either the proxyHost and/or proxyPort configuration is wrong for this proxy host, or that no connection can be established between these two applications (ContainerNursery and FileBrowser for example). Using localhost as proxyHost is only correct if ContainerNursery is run in host networking mode, since otherwise localhost refers to the container and not the Unraid machine. It could be that because of your special network situation the two containers can’t connect to each other, maybe try to investigate more into that direction? You could try (not a permanent solution) to use the default bridge network for both Application and ContainerNursery and simply append the port when you open the url in the browser like so: http://filebrowser.rack:8080 Use the docker container settings to map the ContainerNursery port 80 to port 8080 for example. Then use the Unraid machine IP as proxyHost and the application port (which you have configured using the container settings, like for ContainerNursery) as the proxyPort. Quote Link to comment
guillelopez Posted September 20, 2021 Share Posted September 20, 2021 (edited) 18 hours ago, Echolot said: @guillelopez So just to clarify, the ContainerNursery loading page gets displayed correctly when you visit filebrowser.rack but it just never displays the target application itself? This would mean that either the proxyHost and/or proxyPort configuration is wrong for this proxy host, or that no connection can be established between these two applications (ContainerNursery and FileBrowser for example). Using localhost as proxyHost is only correct if ContainerNursery is run in host networking mode, since otherwise localhost refers to the container and not the Unraid machine. It could be that because of your special network situation the two containers can’t connect to each other, maybe try to investigate more into that direction? You could try (not a permanent solution) to use the default bridge network for both Application and ContainerNursery and simply append the port when you open the url in the browser like so: http://filebrowser.rack:8080 Use the docker container settings to map the ContainerNursery port 80 to port 8080 for example. Then use the Unraid machine IP as proxyHost and the application port (which you have configured using the container settings, like for ContainerNursery) as the proxyPort. That did the trick, I used Bridge Network on ContainerNursery and maped 80 to 8080, then used my Unraid ip as proxyHost. But I need to change also the domain on config.yml to use http://filebrowser.rack:8080, with just http://filebrowser.rack there, ContainerNursery told me on browser "Proxy configuration is missing for http://filebrowser.rack:8080" So my config.yml looks like this: proxyHosts: - domain: filebrowser.rack:8080 containerName: FileBrowser proxyHost: 192.168.1.9 proxyPort: 85 timeoutSeconds: 1800 - domain: krusader.rack:8080 containerName: Krusader proxyHost: 192.168.1.9 proxyPort: 6080 timeoutSeconds: 1800 And ContainerNursery config: Let me know, if you have time, to do more test with other configurations so we can find a perfect use to Unraid. Thanks for your help and your really nice app. Edited September 20, 2021 by guillelopez 1 Quote Link to comment
kjames2001 Posted September 21, 2021 Share Posted September 21, 2021 10 hours ago, guillelopez said: That did the trick, I used Bridge Network on ContainerNursery and maped 80 to 8080, then used my Unraid ip as proxyHost. But I need to change also the domain on config.yml to use http://filebrowser.rack:8080, with just http://filebrowser.rack there, ContainerNursery told me on browser "Proxy configuration is missing for http://filebrowser.rack:8080" So my config.yml looks like this: proxyHosts: - domain: filebrowser.rack:8080 containerName: FileBrowser proxyHost: 192.168.1.9 proxyPort: 85 timeoutSeconds: 1800 - domain: krusader.rack:8080 containerName: Krusader proxyHost: 192.168.1.9 proxyPort: 6080 timeoutSeconds: 1800 And ContainerNursery config: Let me know, if you have time, to do more test with other configurations so we can find a perfect use to Unraid. Thanks for your help and your really nice app. thanks a lot for your tips. i use pihole, so i just add the host names under local dns. 1 Quote Link to comment
Echolot Posted September 21, 2021 Author Share Posted September 21, 2021 @guillelopez Quote That did the trick, I used Bridge Network on ContainerNursery and maped 80 to 8080, then used my Unraid ip as proxyHost. But I need to change also the domain on config.yml to use http://filebrowser.rack:8080, with just http://filebrowser.rack there, ContainerNursery told me on browser "Proxy configuration is missing for http://filebrowser.rack:8080" This is actually a bug! Thanks for reporting this, will look into getting this fixed in the next few days. The port shouldn't be taken into consideration when examining the domain. 1 Quote Link to comment
guillelopez Posted September 21, 2021 Share Posted September 21, 2021 @Echolot At least to add the port on the domain part in config.yml was an easy temporary walkaround. @kjames2001 I'm glad I was helpful. I also use Pi-hole on a raspberry pi, and my router is a pfSense, but couldn't get working it with the Pi-hole local DNS or with the pfSense DNS Resolver. Probably something messy on my config, or I'm forgetting to do some steps. But, for me, the most elegant solution seems to be the provided on the GitHub Project with NginxProxyManager, that let you specify the forward port. Need to learn how to properly implement it on my system. Quote Link to comment
Echolot Posted September 21, 2021 Author Share Posted September 21, 2021 @guillelopez The fix to the bug you discovered, as well as the configurable listening port update was just released two hours ago. I also added the guide I mentioned to the first post. Let me know if somethings missing. Quote Link to comment
guillelopez Posted September 21, 2021 Share Posted September 21, 2021 (edited) 21 minutes ago, Echolot said: @guillelopez The fix to the bug you discovered, as well as the configurable listening port update was just released two hours ago. I also added the guide I mentioned to the first post. Let me know if somethings missing. I removed the domain port on the config file and updated, working perfect. Will make some test with the configurable port at night when I come back home. Thanks a lot for your work. EDIT: Forgot to say that the guide on first post is great even for noobs like me 😄 Edited September 21, 2021 by guillelopez 1 Quote Link to comment
kjames2001 Posted September 22, 2021 Share Posted September 22, 2021 (edited) 17 hours ago, Echolot said: @guillelopez The fix to the bug you discovered, as well as the configurable listening port update was just released two hours ago. I also added the guide I mentioned to the first post. Let me know if somethings missing. just checked out the update, fixed config file. everything works properly, except now the container wont auto update when there's a config change. it used to auto update config when any changes are made. Edited September 22, 2021 by kjames2001 Quote Link to comment
Echolot Posted September 22, 2021 Author Share Posted September 22, 2021 48 minutes ago, kjames2001 said: just checked out the update, fixed config file. everything works properly, except now the container wont auto update when there's a config change. it used to auto update config when any changes are made. I sadly can't recreate your issue, config reloading works just fine on my machines... Is there anymore detail you can provide? Quote Link to comment
guillelopez Posted September 22, 2021 Share Posted September 22, 2021 (edited) 5 hours ago, Echolot said: I sadly can't recreate your issue, config reloading works just fine on my machines... Is there anymore detail you can provide? This what @Kjames should be refering. This happens when I modify the config.yml on Sublime on my desktop Mac, and save it with the container running. Need to restart the container to be able get the change working. This also happened on Unraid with the previus package. If it helps in anyway I run 6.10.0-rc1 Unraid version. I also run ContainerNursery on a Proxmox server where I have some containers, and there I don't have the same issue. But there I modify the config.yml on cli with nano. PD: the configurable port works perfect, I changed to 90 on Unraid and use the default 80 on proxmox. Maybe I going to migrate all the config to proxmox as then I don't have to add the port on the local domains. But still I would be happy to still runing on Unraid to perfom test for you. Edited September 22, 2021 by guillelopez Quote Link to comment
Echolot Posted September 22, 2021 Author Share Posted September 22, 2021 I just tried this using VSCode as the editor on Mac with the container running, can't reproduce this. Do you maybe use a different encoding than UTF-8? Does the same config file that produces this error work after a restart of the container? Quote Link to comment
guillelopez Posted September 22, 2021 Share Posted September 22, 2021 1 hour ago, Echolot said: I just tried this using VSCode as the editor on Mac with the container running, can't reproduce this. Do you maybe use a different encoding than UTF-8? Does the same config file that produces this error work after a restart of the container? On Sublime I was using UTF-8, but yes after restart ContainerNursery, same config file works. It's just when saving it with the container running. Tried to edit and save it from cli with nano on the Unraid system, and instead it works fine at how it should be, no need to restart the container. So definetly something related with the text editor. Would like know what text editor does @kjames2001 use. But for me this is not a big deal. Just restart the container or use nano on cli. Quote Link to comment
kjames2001 Posted September 22, 2021 Share Posted September 22, 2021 10 minutes ago, guillelopez said: On Sublime I was using UTF-8, but yes after restart ContainerNursery, same config file works. It's just when saving it with the container running. Tried to edit and save it from cli with nano on the Unraid system, and instead it works fine at how it should be, no need to restart the container. So definetly something related with the text editor. Would like know what text editor does @kjames2001 use. But for me this is not a big deal. Just restart the container or use nano on cli. 1 hour ago, Echolot said: I just tried this using VSCode as the editor on Mac with the container running, can't reproduce this. Do you maybe use a different encoding than UTF-8? Does the same config file that produces this error work after a restart of the container? 7 hours ago, Echolot said: I sadly can't recreate your issue, config reloading works just fine on my machines... Is there anymore detail you can provide? I'm a noob, so i still use notepad. lol Yeah, not a big deal, but it was super convenient. Because as long as the file is saved after any change, the container updates its config. Quote Link to comment
Echolot Posted September 23, 2021 Author Share Posted September 23, 2021 A small Update v1.4.0 was released, check the second post for the changelog. @guillelopez & @kjames2001 Could you try the config reload issue again with the dev-config tag? ghcr.io/itsecholot/containernursery:dev-config I added a small delay (500ms) after receiving a file change event before trying to read the config file. Maybe this fixes your issue? I sadly still couldn't reproduce this so it's impossible for me to test this on my own. Quote Link to comment
guillelopez Posted September 23, 2021 Share Posted September 23, 2021 1 hour ago, Echolot said: A small Update v1.4.0 was released, check the second post for the changelog. @guillelopez & @kjames2001 Could you try the config reload issue again with the dev-config tag? ghcr.io/itsecholot/containernursery:dev-config I added a small delay (500ms) after receiving a file change event before trying to read the config file. Maybe this fixes your issue? I sadly still couldn't reproduce this so it's impossible for me to test this on my own. With dev-config tag I don't have the reload issue. Seems to work that 500ms delay. Unfortunely for the new "stopOnTimeoutIfCpuUsageBelow" parameter, I don't have a use case yet to test it. Quote Link to comment
Echolot Posted September 23, 2021 Author Share Posted September 23, 2021 31 minutes ago, guillelopez said: With dev-config tag I don't have the reload issue. Seems to work that 500ms delay. Unfortunely for the new "stopOnTimeoutIfCpuUsageBelow" parameter, I don't have a use case yet to test it. That is both good and disappointing to hear lol. Means we found a fix but also means that these editors first save an empty file and then save the correct edited file. The file changed event only gets emitted on the first save since there's an internal debounce logic in the library I use. I will push a small bug fix release in the next few minutes with this change. Quote Link to comment
guillelopez Posted September 23, 2021 Share Posted September 23, 2021 (edited) @Echolot I didn't even thought about something like that hahaha. I thought that may be It were some kind of latency on my local lan that produced that kind of error, as modifying it on nano from ssh console, changes should be made locally. I updated to 1.4.1 with latest tag and now can modify config without restart. 🤘 Edited September 23, 2021 by guillelopez 1 Quote Link to comment
Echolot Posted September 29, 2021 Author Share Posted September 29, 2021 v1.5.0 was just released and adds the feature of stoping (and starting) multiple containers for each proxy host. This is especially useful if your application has multiple supporting containers (database, own reverse proxy, etc.). Quote Link to comment
Alfy1080 Posted November 28, 2021 Share Posted November 28, 2021 Hello. I configured ContainerNursery and it works like a charm. However it sometimes crashes by itself and i have no idea why. This is what i see in the log every time when it crashes: undefined:1 {"read":"2021-11-28T15:03:04.317785879Z","preread":"2021-11-28T15:03:03.283758224Z","pids_stats":{"current":27},"blkio_stats":{"io_service_bytes_recursive":[{"major":8,"minor":112,"op":"Read","value":492716032},{"major":8,"minor":112,"op":"Write","value":32768},{"major":8,"minor":112,"op":"Sync","value":492748800},{"major":8,"minor":112,"op":"Async","value":0},{"major":8,"minor":112,"op":"Discard","value":0},{"major":8,"minor":112,"op":"Total","value":492748800},{"major":8,"minor":160,"op":"Read","value":495140864},{"major":8,"minor":160,"op":"Write","value":106496},{"major":8,"minor":160,"op":"Sync","value":495247360},{"major":8,"minor":160,"op":"Async","value":0},{"major":8,"minor":160,"op":"Discard","value":0},{"major":8,"minor":160,"op":"Total","value":495247360},{"major":7,"minor":2,"op":"Read","value":987856896},{"major":7,"minor":2,"op":"Write","value":139264},{"major":7,"minor":2,"op":"Sync","value":987996160},{"major":7,"minor":2,"op":"Async","value":0},{"major":7,"minor":2,"op":"Discard","value":0},{"major":7,"minor":2,"op":"Total","value":987996160}],"io_serviced_recursive":[{"major":8,"minor":112,"op":"Read","value":120292},{"major":8,"minor":112,"op":"Write","value":4},{"major":8,"minor":112,"op":"Sync","value":120296},{"major":8,"minor":112,"op":"Async","value":0},{"major":8,"minor":112,"op":"Discard","value":0},{"major":8,"minor":112,"op":"Total","value":120296},{"major":8,"minor":160,"op":"Read","value":120884},{"major":8,"minor":160,"op":"Write","value":7},{"major":8,"minor":160,"op":"Sync","value":120891},{"major":8,"minor":160,"op":"Async","value":0},{"major":8,"minor":160,"op":"Discard","value":0},{"major":8,"minor":160,"op":"Total","value":120891},{"major":7,"minor":2,"op":"Read","value":15399},{"major":7,"minor":2,"op":"Write","value":12},{"major":7,"minor":2,"op":"Sync","value":15411},{"major":7,"minor":2,"op":"Async","value":0},{"major":7,"minor":2,"op":"Discard","value":0},{"major":7,"minor":2,"op":"Total","value":15411}],"io_queue_recursive":[],"io_service_time_recursive":[],"io_wait_time_recursive":[],"io_merged_recursive":[],"io_time_recursive":[],"sectors_recursive":[]},"num_procs":0,"storage_stats":{},"cpu_stats":{"cpu_usage":{"total_usage":1580673183827,"percpu_usage":[136591228373,106160781099,127593972219,148154351579,144195817404,132300399864,122134487960,118729123484,135504818319,137865795981,134722498298,136719909247,0,0,0,0],"usage_in_kernelmode":310490000000,"usage_in_usermode":984030000000},"system_cpu_usage":1782568880000000,"online_cpus":12,"throttling_data":{"periods":0,"throttled_periods":0,"throttled_time":0}},"precpu_stats":{"cpu_usage":{"total_usage":1580668857736,"percpu_usage":[136588457807,106160781099,127593972219,148154254726,144195817404,132300258201,122134487960,118729123484,135504725654,137865795981,134722498298,136718684903,0,0,0,0],"usage_in_kernelmode":310490000000,"usage_in_usermode":984030000000},"system_cpu_usage":1782556530000000,"online_cpus":12,"throttling_data":{"periods":0,"throttled_periods":0,"throttled_time":0}},"memory_stats":{"usage":555679744,"max_usage":758505472,"stats":{"active_anon":0,"active_file":26578944,"cache":56770560,"dirty":0,"hierarchical_memory_limit":9223372036854771712,"hierarchical_memsw_limit":9223372036854771712,"inactive_anon":496332800,"inactive_file":22499328,"mapped_file":25681920,"pgfault":6842979,"pgmajfault":1155,"pgpgin":11106612,"pgpgout":11076689,"rss":487251968,"rss_huge":69206016,"total_active_anon":0,"total_active_file":26578944,"total_cache":56770560,"total_dirty":0,"total_inactive_anon":496332800,"total_inactive_file":22499328,"total_mapped_file":25681920,"total_pgfault":6842979,"total_pgmajfault":1155,"total_pgpgin":11106612,"total_pgpgout":11076689,"total_rss":487251968,"total_rss_huge":69206016,"total_unevictable":0,"total_writeback":0,"unevictable":0,"writeback":0},"limit":12552155136},"name":"/emby","id":"e6fd7da6a145a05ac3e6d5af16b85f9ebfa38c362072e9970646c16a5d53053e","networks":{"eth0":{"rx_bytes":667201285,"rx_packets":580695,"rx_errors":0,"rx_dropped":0,"tx_bytes":188815145,"tx_packets":290544,"tx_erro SyntaxError: Unexpected end of JSON input at JSON.parse (<anonymous>) at IncomingMessage.<anonymous> (/usr/src/app/build/DockerManager.js:112:62) at IncomingMessage.emit (node:events:390:28) at addChunk (node:internal/streams/readable:315:12) at readableAddChunk (node:internal/streams/readable:289:9) at IncomingMessage.Readable.push (node:internal/streams/readable:228:10) at HTTPParser.parserOnBody (node:_http_common:141:24) at Socket.socketOnData (node:_http_client:487:22) at Socket.emit (node:events:390:28) at addChunk (node:internal/streams/readable:315:12) Any idea what could cause this issue? Regards! Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.