From TomAI Containers: sb-homarr, memory limit 512M (media/homarr module) Symptom: Homarr crashes on a cycle — dies with Aborted (core dumped) after JS heap exhaustion (mark-compact GC failed), restarts, runs a few minutes, dies again. Confirmed via logs: repeated TRPCError: NOTFOUND — No home board found right before each crash, alongside iconsUpdaterJobs icon-cache refresh (~28k icons). What's been tried: Bumped memory limit to 512M previously — fixed it temporarily. Did a clean restart (restartcontainer) after latest crash — did NOT hold, container was back to ~4min uptime with same OOM signature shortly after. Suspected cause: Homarr appears to be retrying/rebuilding on every request because no default home board is assigned, and that failed-lookup loop is contributing to memory climbing back to the ceiling — not just the icon refresh job alone. 512M may not be the real fix if the board-lookup failure isn't resolved first. Ask: Look at whether a missing/unassigned home board can trigger a render-retry loop that leaks or balloons memory, and whether the default memory limit needs raising regardless. From me: I do have a home board all set up.
5 replies
Chris wrote:
You didn't do anything wrong here, and the 512MB limit you're seeing is already the current default (it got bumped up from 256MB a while back for exactly this kind of crash). What you're describing sounds like a separate issue on top of that though -- a genuine board-lookup loop causing repeated crashes even with a board set up and the higher memory ceiling. Your logs and diagnosis are solid, so I've flagged this with the team to dig into the retry/leak behavior specifically -- not just the memory limit. Thanks for the detailed writeup, it'll help track this down faster.
Chris wrote:
Good news — Tom's team shipped a fix built from this report in v1.6.542. SparkBox no longer bounces Homarr on that "No home board found" error — the restart churn was feeding the crash cycle, and the message no longer tells you to set up a board you already have. Grab it with sudo sparkbox upgrade. The memory side is still being watched: if Homarr keeps dying with the same OOM signature after this, post the new uptime pattern here — that tells Tom's team whether the board-lookup loop itself is still leaking, which is the part they want to nail next.
Doc_Senna wrote:
I updated SparkBox and seem to be having the same trouble still. Here is the update from TomAI Update — confirmed still happening after latest restart, logs attached Pulled fresh logs off the box just now (10 Aug 04:05-04:06 window). Still the same signature: ⨯ Error [TRPCError]: No home board found at async getInitialBoardAsync (...) at async page (...) code: 'NOTFOUND' Firing repeatedly on every rsc tRPC request (userId="undefined" userName="undefined" — worth noting these requests look unauthenticated), roughly 30 seconds apart. This lines up exactly with what I posted originally: the board exists and is set up on my end, but getInitialBoardAsync is failing the lookup anyway and throwing NOTFOUND on repeat, not a one-time cold-start miss. Restarting the container does NOT clear this — it comes back within minutes on the same cycle. So whatever's resolving "home board" at request time isn't finding it consistently, even though the board is real and configured. That tracks with my original theory: this failed lookup is retrying per-request rather than failing once and caching a result, which would explain both the memory climb back to the 512M ceiling and the crash loop repeating regardless of the memory bump. Given the userId="undefined" on these requests — is it possible the home-board lookup is scoped to a user/session that isn't resolving on these particular requests (something in how the default board gets served pre-auth or on SSR), rather than the board itself being missing from the DB? That would explain "board exists in UI" + "NOTFOUND in logs" not being a contradiction. Raising the memory limit again isn't going to fix this if the underlying retry loop is what's driving memory up — asking for someone to look at the getInitialBoardAsync path directly rather than another memory bump.
Chris wrote:
Really solid follow-up, DocSenna -- the userId="undefined" detail is a good catch, and it doesn't fit the plain "board got renamed" explanation we shipped for, so I'm passing that along as-is for someone to look at the lookup path directly. In the meantime, since it's still failing: open Homarr right after a restart and re-pick the board in BOTH spots even though one already looks set -- Management - Settings - Boards (the global default), and your avatar - Your preferences - Home board (yours) -- saving each one. If it still throws the same error after saving both, that's exactly the evidence needed to rule out a stale pointer, so keep posting logs here.
Chris wrote:
Following up on this one — the lookup path got looked at, and the answer was on our side. That error was coming from SparkBox's own health check. It was checking on Homarr by loading its board page, and it does that signed out, so Homarr tried to resolve a home board for nobody — every 30 seconds, forever. That's your userId="undefined", and it's why it kept firing no matter how many times you re-picked the board. Tom shipped v1.6.546 today: the check now uses Homarr's status page, which doesn't touch boards at all. Update with Settings → Updates → Update SparkBox, and that log should go quiet. If it doesn't, post again and we'll keep digging.