iii-engine Docker container (iiidev/iii:0.11.2) fills disk space with massive 129GB stdout json.log

[satabd]

Describe the bug
When running the iii-engine via Docker (iiidev/iii:0.11.2) as part of the agentmemory stack, the container generates an extreme amount of stdout/stderr logs. In our environment, the container's /var/lib/docker/containers/.../...-json.log file reached 129 GB in size, completely consuming the host's disk space.

This appears to be caused by the engine getting stuck in a rapid crash/restart or error-spam loop, dumping massive amounts of stack traces or error logs to stdout.

To Reproduce

1. Run agentmemory Docker Compose stack with iiidev/iii:0.11.2
2. Allow it to run for some time (especially if it encounters an internal server error or network issue)
3. Check the container log file size (du -sh /var/lib/docker/containers/<container-id>)
4. Notice massive disk consumption.

Expected behavior

1. The iii-engine should not spam standard output infinitely on failure.
2. The docker-compose.yml for agentmemory should implement Docker logging limits (e.g., max-size: "10m", max-file: "3") to prevent unbounded disk growth.

Environment:

• OS: Windows WSL2 / Docker Desktop
• Docker Image: iiidev/iii:0.11.2
• Container Name: agentmemory-iii-engine-1

[rohitg00]

Thanks @satabd — opened #280 with the compose-side guardrail you suggested: logging.driver: json-file with max-size: 10m and max-file: 3 on the iii-engine service. That caps total engine log on disk at 30 MB regardless of what the engine does inside.

The blast-radius bound is the right thing to land in agentmemory itself — but what's actually filling 129 GB is upstream iiidev/iii:0.11.2 getting stuck in a crash/restart or error-spam loop, and that needs fixing in iii-hq/iii, not here. To file that with concrete data instead of speculation, I need to see the spam pattern.

Can you share ~50-100 representative lines from your container log (sample from a few points across the 129 GB to catch repeating patterns vs one-shot stack traces)? Something like:

# tail the most recent activity
docker logs --tail 100 agentmemory-iii-engine-1 > /tmp/engine-tail.log

# sample from the middle of the giant log file (replace <id>)
CONTAINER_LOG="/var/lib/docker/containers/<id>/<id>-json.log"
head -n 100 "$CONTAINER_LOG" > /tmp/engine-head.log
tail -n 100 "$CONTAINER_LOG" > /tmp/engine-tail-raw.log

Specifically interested in:

• Is it the same line repeating at high frequency, or many different errors?
• Any stack traces with file paths into the engine binary?
• Restart markers (worker disconnect / reconnect lines)?
• A specific HTTP error / "internal server error" right before the spam starts?

Once I have that pattern I'll file a precise issue against iii-hq/iii. Until then #280 keeps your disk safe even when the engine misbehaves.

(Separately: if you can also share docker info | grep -i log and your Docker Desktop version, I can confirm whether the json-file driver default is what you're already on, since Docker Desktop on Windows occasionally defaults to a different driver where these compose options would be ignored.)