Skip to content

Troubleshooting

Jump to bottom
o51r15 edited this page Jul 11, 2026 · 1 revision

Troubleshooting

ExitCode 0 with many restarts

When Docker shows ExitCode 0 with restarts > 0, the process is exiting cleanly at startup — not crashing at runtime. In bitmagnet this almost always means the fx dependency injection framework couldn't wire up successfully.

Common causes:

  • Can't reach Postgres (wrong hostname, container not ready, network misconfiguration)
  • Config validation error (malformed config.yml, bad env var value)

Diagnosis: Check the first ~20 lines of each restart cycle in docker logs bitmagnet. The error will be at the top, not buried in runtime output.

DHT shows Inactive on dashboard

If using a sidecar deployment, make sure:

  1. The main instance has DHT_CRAWLER_SIDECAR_ENABLED=true and DHT_CRAWLER_SIDECAR_URL=http://gluetun:3333
  2. The sidecar runs --keys=http_server alongside --keys=dht_crawler
  3. Both the main instance and gluetun are on the shared Docker network (bitmagnet-net)

Note: the environment variable names use underscores between words — DHT_CRAWLER_SIDECAR_ENABLED, not DHT_CRAWLER_SIDECARENABLED.

Prowlarr crawl shows imported: 0

If logs show "imported": 0, "new_results": 35+ every cycle, that indexer doesn't return torrent hashes and is not compatible with bitmagnet. Try a different indexer. See the compatibility list in Prowlarr Integration.

TMDB classification stalls

TMDB API calls route through the VPN exit node (if using gluetun). If that node has poor routing to TMDB's CDN, timeouts spike. The classifier automatically disables TMDB temporarily and re-enables when connectivity returns.

Fix: Try a different VPN server country, or set TMDB_ENABLED=false if you don't need content metadata.

DHT bootstrap WARN messages

During VPN instability, DNS for DHT bootstrap nodes times out. This shows as WARN in logs and triggers automatic reseed. These warnings are normal and recover on their own. Only investigate if the ktable stays empty for more than 10 minutes.

Postgres crash loops after VPN outage

Postgres must NOT share gluetun's network namespace. If Postgres is on network_mode: service:gluetun, VPN drops take the database offline and cause crash loops.

Fix: Give Postgres its own Docker bridge network. See Gluetun VPN Deployment.

Reading docker inspect output

docker inspect --format='{{.State.ExitCode}} {{.RestartCount}} {{.State.Status}}' bitmagnet
  • ExitCode 0 + restarts = startup failure (config/connectivity)
  • ExitCode 1 + restarts = runtime crash (check logs for panic)
  • ExitCode 137 = OOM killed (increase memory limit in compose)

Clone this wiki locally