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. Per-host worker queue isn't being consumed¶

Container creates are routed to per-host Celery queues named compute-<ip-with-dashes> (e.g. compute-192-168-10-56). If the worker on that host isn't listening to that queue, the task sits in Redis forever.

Check on the master:

docker compose exec redis redis-cli LLEN compute-192-168-10-56
# Non-zero = unconsumed tasks

Check the worker on the LXD host:

journalctl -u mfcloud-agent -n 50
# Should show "celery@hostname ready" and "[tasks] containers.create_container"

If the worker isn't subscribed to the per-host queue, Containers → host row → 🛠 Repair Agent. This re-pushes worker code (including core/lxd.py and core/ssh.py) and restarts the systemd unit.

2. `ModuleNotFoundError: core.lxd` on the worker¶

Earlier worker deploys synced only tasks/. The repair-agent flow now also pushes core/lxd.py and core/ssh.py. If you see this error, run Repair Agent once.

3. LXD daemon down¶

# On the LXD host
systemctl status lxd
lxc list   # if this hangs, LXD is wedged

systemctl restart lxd usually unsticks it.

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