Dashboard Up & Nothing Works
Posted by 1ye
Moved from WSL to UGREEN NAS DH2300. Upgraded Sparkbox to v1.6.736 . Dashboard slowly populates, but nothing opens or runs, not even Tom AI. Sparkbox Doctor shows : [Container Health] [ERROR] sb-radarr is running, but its health check is failing (Docker reports 'unhealthy') The app has started but is not answering properly, so it will look broken or half-working. Last few log lines: │ [Info] AppFolderInfo: Data directory is being overridden to [/config] │ [Debug] Bootstrap: Starting in Interactive mode │ [Info] AppFolderInfo: Data directory is being overridden to [/config] [ERROR] sb-lidarr crashed (exit code 128) [ERROR] sb-byparr crashed (exit code 143) [ERROR] sb-sabnzbd is running, but its health check is failing (Docker reports 'unhealthy') The app has started but is not answering properly, so it will look broken or half-working. Last few log lines: │ [sab-preinit-port] hostwhitelist already current (sb-gluetun, sb-sabnzbd, dh2300-9d53, dh2300-9d53.local, vault.sparkbox.local) — no-op │ [sab-preinit-port] done │ [custom-init] 01-set-port.sh: exited 0 [ERROR] sb-prowlarr crashed (exit code 137) [ERROR] sb-bazarr is running, but its health check is failing (Docker reports 'unhealthy') The app has started but is not answering properly, so it will look broken or half-working. Last few log lines: │ 2026-09-20 17:42:27,607 - root (7f72036a28) : INFO (signalrclient:124) - BAZARR trying to connect to Sonarr SignalR feed... │ 2026-09-20 17:42:27,613 - waitress (7fa13d8d20) : INFO (wasyncore:449) - BAZARR is started and waiting for requests on: http://[::]:6767 │ 2026-09-20 17:42:27,618 - root (7f71e19a28) : INFO (signalrclient:191) - BAZARR trying to connect to Radarr SignalR feed... [ERROR] sb-gluetun is stuck in a crash-restart loop (7 restarts so far) │ 2026-09-20T17:53:43+09:00 INFO [routing] local ipnet found: 172.20.5.0/24 │ 2026-09-20T17:54:00+09:00 INFO [firewall] enabling... │ 2026-09-20T17:54:01+09:00 INFO [firewall] enabled successfully [ERROR] sb-jellyfin-media is running, but its health check is failing (Docker reports 'unhealthy') The app has started but is not answering properly, so it will look broken or half-working. Last few log lines: │ [17:52:30.104] [WRN] [16] Microsoft.AspNetCore.Server.Kestrel: As of "09/20/2026 08:52:29 +00:00", the heartbeat has been running for "00:00:01.3049484" which is longer than "00:00:01". This could be caused by thread pool starvation. │ [17:52:40.278] [WRN] [16] Microsoft.AspNetCore.Server.Kestrel: As of "09/20/2026 08:52:40 +00:00", the heartbeat has been running for "00:00:01.1717717" which is longer than "00:00:01". This could be caused by thread pool starvation. │ [17:53:45.202] [WRN] [16] Microsoft.AspNetCore.Server.Kestrel: As of "09/20/2026 08:53:45 +00:00", the heartbeat has been running for "00:00:01.2429447" which is longer than "00:00:01". This could be caused by thread pool starvation. [ERROR] sb-seerr is running, but its health check is failing (Docker reports 'unhealthy') The app has started but is not answering properly, so it will look broken or half-working. Last few log lines: │ │ 2026-09-20T07:55:31.761Z [info]: Commit Tag: [HEXREDACTED] │ 2026-09-20T08:01:46.017Z [info]: Starting Seerr version 3.4.1 [ERROR] sb-dashboard is running, but its health check is failing (Docker reports 'unhealthy') The app has started but is not answering properly, so it will look broken or half-working. Last few log lines: │ [alerts] Auto-restarting sb-radarr (attempt 1/3) │ [alerts] sb-qbittorrent is stopped │ [alerts] Auto-restarting sb-qbittorrent (attempt 1/3) [ERROR] sb-homepage is running, but its health check is failing (Docker reports 'unhealthy') The app has started but is not answering properly, so it will look broken or half-working. Last few log lines: │ - Network: http://[::]:3000 │ ✓ Ready in 0ms │ ✓ Running next.config took 4.1s Try: sudo sparkbox up (and 'sparkbox logs <name' to see why a container is unhappy) sb-lidarr: exit code 128, OOM-killed: false, stopped at 2026-09-20T08:29:52 sb-byparr: exit code 143, OOM-killed: false, stopped at 2026-09-20T08:30:23 sb-prowlarr: exit code 137, OOM-killed: false, stopped at 2026-09-20T08:48:08 [WARN] Load average 40.43 on 8 core(s) -- the box is working flat out Busiest app right now: sb-gluetun (2.67% CPU) A library scan, a transcode or a big import is normal for a while. If it stays like this for hours, restart that app from the dashboard's Apps page or ask Tom AI. Rebooted NAS. Switched LAN cables. Switched LAN ports. Changed router settings. Absolutely nothing works properly. I need to reset license keys and kill this box. How to fix this?
3 replies
Chris wrote:
Sorry — this one is on us, and you do not need to wipe the box or touch your licence to get out of it. What is actually happening: your load line is the tell. Load 40 on 8 cores while the busiest app is at under 3% CPU means no app is busy — the box itself is waiting on its disk or memory, most likely because the whole media stack came up at once on a NAS with far less headroom than your WSL machine had. Every app was alive but too starved to answer its health check in time, and SparkBox then did the wrong thing: it treated each red tile as a crash and restarted it, up to three times every five minutes, and every time the VPN container hiccupped it also restarted the nine apps that ride on it. Each restart is a fresh start-up on a box already past its limit, so the restarts kept the load at 40 and turned "slow" into "nothing works". The three apps doctor lists as crashed were killed by those restarts, not by their own faults. Doctor's "restart that app" advice was wrong for this case too. This is fixed in SparkBox 1.6.739, out now: while the box is overloaded SparkBox stops restarting apps, says so on the alert, and resumes on its own once the load drops; doctor now tells you the box is starved instead of pointing at an app. One next step: run sudo sparkbox upgrade, give it fifteen minutes with nothing else running, then paste the [System Resources] and [VPN Tunnel] sections from sudo sparkbox doctor here. Those two tell us how much memory this NAS has left and why the VPN container itself keeps exiting, which is the one thing the output above does not show. If the memory line is under about 1 GB free, turning off the apps you do not use (from the Apps page) is the real fix on a box this size — the DH2300 is an 8-core ARM NAS and the full media bundle is a lot for it. We have corrected what SparkBox and its assistant know about this so the next person on a small NAS does not get restarted into the same hole.
1ye wrote:
Before going any further, need to establish a baseline-- a working, stable, reliable baseline. Have a mini PC that can run WSL, but have had no lasting success since install. Transferred to NAS DH2300, with same misery. Only other option available to me at this time is a Raspberry Pi 5 that can run Linux. Which of these is best to run a full, reliable, stable, working stack? I shouldn't have to cast spells to make all this work.
Chris wrote:
You’re right — you should not have to keep changing platforms and casting spells just to get a stable baseline. I’m sorry the earlier answer focused on recovering this overloaded NAS instead of answering which host is the best starting point. For the full SparkBox stack, use the x8664 mini PC running Linux/WSL Docker Engine if it has at least 8 GB of RAM; that is the safer choice of your three options. The UGREEN DH2300 is supported as a Docker NAS, but your diagnostic shows this particular full stack is overwhelming it: load 40.43 on 8 cores while the busiest container used only 2.67% CPU, so the whole box was starved rather than one app being faulty. A Raspberry Pi 5 is not an officially supported SparkBox platform because SparkBox targets x8664, so I would not use it for this baseline. One next check: on the mini PC, tell me whether Docker is Docker Desktop or Docker Engine inside WSL, and paste only the RAM amount and CPU model from that host. Do not move the data or reset licence keys yet. I’ve corrected the guidance so this platform choice and the distinction between an overloaded NAS and an app failure are not missed for the next person.