When Your Home Server Runs Dozens of Containers: Why Power and I/O Aren't a Detail
Following up on a promise from the Frigate on Orange Pi 5 article — where it was deliberately just one sentence, here's the full story.
Why this article exists
When a small SBC runs twenty-nine Docker containers at once — media stack, home automation, AI camera detection, custom apps — it's tempting to blame software for any problem that comes up. There's so much running that surely something just overflowed.
That's exactly what happened to me. The server would occasionally become unreachable, come back fine after a physical restart, and the first suspicion pointed at the containers. The real cause turned out to be twofold — and neither half was in Docker.
First symptom: a kernel panic that looked like software
The server stopped responding. A photo of the console showed:
Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
After a physical power-cycle, the server was back. The first check turned up something convincing: two services stuck in an infinite restart loop — one app whose port was already held by another process, and another waiting on a USB device that wasn't connected. Both were restarting every five seconds, thousands of times combined. System load dropped from 15 to 8 the moment they were disabled.
Looked solved. It wasn't.
When the apparent cause doesn't hold up, go deeper
A few days later the panic came back — without those two services. Time for a more systematic search:
- The panic trace store (pstore) was empty — the kernel does have
CONFIG_PSTORE_RAM=y, but the device tree had no reserved memory to actually save a panic log into. So after every crash, the one record that would have helped most simply vanished. - Kernel version history suggested a correlation with one particular branch, but switching back to the original kernel didn't stop the crashes either — so it wasn't the kernel by itself.
- SMART data on both drives was clean — no growing error counts, no evidence of a fresh disk failure.
- USB topology showed that both drives (system and data) hang off the same USB3 hub under a single controller — a potential source of contention, but still just a hypothesis at this point.
It was a physical inspection of a photo of the power adapter that finally produced a convincing lead: the dual-port PD adapter had a bold "30 W" printed on the label, but at 5 V — the voltage the SBC actually needs — it could only deliver 5V/3A, 15 W, and less than that with both ports in use at once. The board itself demands up to 5V/4A, i.e. 20 W, under load spikes. The big number on the label only applied at the higher voltages of USB-C PD profiles, which have nothing to do with the 5 V rail a single-board computer actually runs on.
Exactly the kind of detail that's easy to overlook when buying one — the adapter looks powerful enough, but the number on the box and the actual output at the voltage you need are two different things.
Don't trust a guess — verify with data
Instead of speculating about whether the adapter really was the culprit, I reached for data that already existed — a smart plug on Home Assistant had been logging the server branch's power draw for a long time. Comparing before and after the adapter swap showed exactly what the theory predicted: spikes that used to hit the ceiling of the old supply (~15 W) now showed up cleanly as their real 12–17 W after the swap — and the new 27 W/5.1V-5A supply still had almost a third of headroom left even at that peak.
The new adapter (the same type as the official Raspberry Pi 27 W supply) went in, and there hasn't been a single kernel panic or undervoltage message in the logs since. As a belt-and-suspenders measure — not a substitute for the actual fix — I also set kernel.panic=15 (auto-reboot instead of hanging forever) and enabled the hardware watchdog. If something similar ever happens again, the server will at least recover on its own while the cause gets tracked down.
A second, independent problem hiding under the same label of "instability"
Here's the part that surprised me most: even after replacing the adapter, a completely separate problem remained on the table — one that had been hiding under the exact same "dirty boots" heading all along: a slow disk.
The database container (Joplin/Postgres) had checkpoint times that had jumped, a month earlier, from 2–9 seconds to a steady 10–12 seconds. A benchmark run directly on the data drive showed fsync latency around 75–100 ms and only 11–13 IOPS single-threaded — under concurrent load from four processes, the average jumped to 200 ms, with spikes up to 1.5 seconds. For comparison, the system SSD on the same machine handled the same kind of write at 290 IOPS (roughly 3.4 ms per write) — about 25 to 30 times faster.
The reason: several database-backed containers were all writing to a slower, USB-attached drive that also shared a controller with a second drive. The fix wasn't tuning parameters — it was moving nine services with their own database (Sonarr, Radarr, Prowlarr, Jellyseerr, Bazarr, Navidrome, and others) onto the faster system SSD. After the move, checkpoint time dropped to 0.027 seconds — a hundred-plus-fold speedup in actual disk writes.
The key lesson from this part: power and I/O were two completely independent problems, both showing up as general "system instability." Fixing one didn't fix the other — and if I'd stopped after replacing the adapter and called it a win, the databases would have kept suffering from slow writes.
Even a plain external drive can ask for its own power
This isn't unique to one SBC — the same principle showed up with a physical external drive that serves as the main backup storage target. Under load spikes (for example, when AI camera detection was running across four 4K cameras at once), the server would crash under load until the drive was moved onto its own powered USB hub. After the move to a powered hub, the problem disappeared. Same pattern, different component: when peak draw exceeds what a given USB bus/port can actually supply, the result looks like software instability, even though it's purely electrical.
What to take away if you're running a lot of services on one machine
- Don't rush to blame software as the first suspect. Restarting services can be a symptom of a busy system, not the cause of a crash.
- A power label with a big number isn't a guarantee. Check the real output at the voltage the device actually uses — not just the maximum the adapter can deliver under some other profile.
- If you can measure real draw (e.g. a smart plug), use it. A week of production data is more convincing than any theory.
- Multiple drives on one USB controller/hub is contention waiting for its moment. It shows up exactly when load is highest — which is exactly when it hurts most.
- Two different problems can wear the same disguise. Systematic elimination (SMART, logs, benchmarks, history) is slower than believing the first convincing theory, but it's the only way to say "done" with any confidence.
If your homelab runs on a similarly small but heavily loaded machine, it's worth running through exactly this checklist once in a while — before another midnight kernel panic forces you to.