Title
URL/web-page assets fail to display on x86 install (Debian 13) — Docker starts before DNS is actually ready, despite network-online.target being satisfied
Environment
- Anthias version: v2026.7.4 (commit 33fe606)
- Hardware: Intel NUC (x86)
- OS: Debian 13
- Install method: standard x86 install script
- Active wait-online provider: NetworkManager-wait-online.service
Description
On this x86 install, local image assets display without any issue. URL/web-page assets, however, fail to display — no explicit error shows up in the Anthias dashboard. The display either skips straight past the asset or just shows the default Anthias logo/black screen, as if no asset were configured.
What I found while debugging
docker logs anthias-anthias-viewer-1 occasionally showed lines like Asset ... is not available, skipping for URL assets specifically, while image assets logged fine. Full log excerpt attached.
- I tried switching the system DNS to
8.8.8.8 as a debug step, based on forum reports of similar network-resolution issues on x86 installs (see "Related" below), to test whether the local DNS resolver was somehow involved. That made URL assets start working.
- Switching DNS back afterward also kept it working — so the DNS server itself wasn't actually the fix.
- To isolate this further, I then tried just restarting the Anthias containers on their own, without touching DNS at all (
docker compose down followed by docker compose up -d). That alone also fixed it — confirming it wasn't DNS-specific, but rather something about a restart in general resetting a bad state. This fix did not persist across a reboot, though, which is what led me to look at boot-time timing instead.
- This pointed toward a network-readiness race condition at boot, so I tried delaying Docker startup:
- First tried making
docker.service wait on network-online.target:
[Unit]
After=network-online.target
Wants=network-online.target
This alone did not fix the issue, even though NetworkManager-wait-online.service (the active provider on this system) reports success before Docker starts.
- Only adding a hardcoded delay on top actually fixed it reliably:
[Service]
ExecStartPre=/bin/sleep 10
Both are applied via sudo systemctl edit docker.service. Since adding the hardcoded sleep, URL/web-page assets have loaded reliably on every boot.
Note: the 10s value was not derived from measurement — it was a guess that happened to work. The actual minimum required delay on this hardware is unknown and could be shorter or need to be longer on slower networks/hardware.
Hypothesis
Race condition on x86 installs: Docker (and therefore the Anthias containers) starts before DNS resolution is actually functional, even though NetworkManager-wait-online.service / network-online.target reports ready. Local image assets aren't affected since they don't need external DNS resolution at that moment. URL assets fail at the point the viewer first tries to resolve/fetch them right after boot, and there doesn't seem to be a retry afterward — so the asset stays "broken" until something (DNS change, container/docker restart) resets that state.
The fact that network-online.target alone wasn't sufficient suggests NetworkManager-wait-online.service returns "online" before DNS is actually usable on this system, which may be worth flagging as its own upstream issue too (or working around defensively on Anthias's side).
Steps to reproduce
- Fresh x86 install of Anthias on an Intel NUC, Debian 13
- Add one local image asset and one URL/web-page asset
- Reboot the device
- Image asset displays correctly; URL asset is skipped/blank, with no error shown in the dashboard
Workaround
A hardcoded delay before Docker starts (ExecStartPre=/bin/sleep 10 in a docker.service systemd override) resolves the issue reliably in my testing. Waiting on network-online.target alone was not sufficient. A plain docker restart also works as a one-off fix but doesn't survive a reboot.
Related
Logs
anthias-debug-20260730-125123.tar.gz
Title
URL/web-page assets fail to display on x86 install (Debian 13) — Docker starts before DNS is actually ready, despite network-online.target being satisfied
Environment
Description
On this x86 install, local image assets display without any issue. URL/web-page assets, however, fail to display — no explicit error shows up in the Anthias dashboard. The display either skips straight past the asset or just shows the default Anthias logo/black screen, as if no asset were configured.
What I found while debugging
docker logs anthias-anthias-viewer-1occasionally showed lines likeAsset ... is not available, skippingfor URL assets specifically, while image assets logged fine. Full log excerpt attached.8.8.8.8as a debug step, based on forum reports of similar network-resolution issues on x86 installs (see "Related" below), to test whether the local DNS resolver was somehow involved. That made URL assets start working.docker compose downfollowed bydocker compose up -d). That alone also fixed it — confirming it wasn't DNS-specific, but rather something about a restart in general resetting a bad state. This fix did not persist across a reboot, though, which is what led me to look at boot-time timing instead.docker.servicewait onnetwork-online.target:[Unit] After=network-online.target Wants=network-online.targetThis alone did not fix the issue, even though
NetworkManager-wait-online.service(the active provider on this system) reports success before Docker starts.[Service] ExecStartPre=/bin/sleep 10Both are applied via
sudo systemctl edit docker.service. Since adding the hardcoded sleep, URL/web-page assets have loaded reliably on every boot.Note: the 10s value was not derived from measurement — it was a guess that happened to work. The actual minimum required delay on this hardware is unknown and could be shorter or need to be longer on slower networks/hardware.
Hypothesis
Race condition on x86 installs: Docker (and therefore the Anthias containers) starts before DNS resolution is actually functional, even though
NetworkManager-wait-online.service/network-online.targetreports ready. Local image assets aren't affected since they don't need external DNS resolution at that moment. URL assets fail at the point the viewer first tries to resolve/fetch them right after boot, and there doesn't seem to be a retry afterward — so the asset stays "broken" until something (DNS change, container/docker restart) resets that state.The fact that
network-online.targetalone wasn't sufficient suggestsNetworkManager-wait-online.servicereturns "online" before DNS is actually usable on this system, which may be worth flagging as its own upstream issue too (or working around defensively on Anthias's side).Steps to reproduce
Workaround
A hardcoded delay before Docker starts (
ExecStartPre=/bin/sleep 10in adocker.servicesystemd override) resolves the issue reliably in my testing. Waiting onnetwork-online.targetalone was not sufficient. A plaindocker restartalso works as a one-off fix but doesn't survive a reboot.Related
Logs
anthias-debug-20260730-125123.tar.gz