Skip to content

[BUG] 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 #3230

Description

@Nature1Limited

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:
    1. 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.

  1. 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

  1. Fresh x86 install of Anthias on an Intel NUC, Debian 13
  2. Add one local image asset and one URL/web-page asset
  3. Reboot the device
  4. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions