Skip to content

Container Stuck "Queued" / "Creating"

A new container row stays at Queued or Creating indefinitely and the task drawer shows nothing happening.

Most likely causes

1. The master's own Celery worker isn't consuming the celery queue

Unlike VM tasks, container tasks (create_container, delete_container, migrate_container, TurnKey import, etc.) all route to the master's own queue (celery), not a per-host compute-<ip-with-dashes> queue — they need core.lxd.LXDClient, which requires the master's mTLS cert pair, and a per-host worker only ships tasks/ (no core/), so it can't import that module. If the master's worker isn't consuming celery, the task sits in Redis forever.

Check on the master:

docker compose exec redis redis-cli LLEN celery
# Non-zero and not draining = unconsumed tasks

docker compose logs worker --tail 50
# Should show "celery@<host> ready"

Container status is written by a direct DB call from the worker, not an HTTP callback, so if the master's worker container is unhealthy or restarting, container creates stall regardless of the LXD host's own state. Restart the worker container if it's not consuming.

(VM tasks — virsh/zfs/etc. — still legitimately route to per-host compute-<ip-with-dashes> queues; if a VM is stuck Queued, check the target compute node's worker instead, not the master's.)

2. LXD daemon down on the target node

LXD is deployed via snap — systemctl status lxd / systemctl restart lxd will report "Unit lxd.service not found" on these nodes:

# On the LXD host
snap services lxd
lxc list   # if this hangs, LXD is wedged

snap restart lxd (fallback: systemctl restart snap.lxd.daemon) usually unsticks it.

3. TLS trust mismatch (V38.5-S1 fingerprint pinning)

If the LXD host was reinstalled, the master's stored fingerprint doesn't match the new self-signed cert. Worker logs will show:

[LXD] server fingerprint mismatch — possible MITM or re-installed daemon

Fix: Containers tab → host row → 🛡 Re-trust, then retry.

After unblocking

Existing stuck rows stay in Creating because the Celery task that would update them is still sitting in Redis. Either:

  • Wait — once the queue is consumed, the worker picks up the stale tasks and runs them. Old container_name might collide if you've already retried, in which case the task fails cleanly.
  • Force-clean — docker compose exec redis redis-cli FLUSHDB (nukes ALL queued tasks across all hosts) then delete the Creating rows from the UI and recreate.

See also