fix: restore RotatingFileHandler to prevent OOM from unbounded log growth

[spomichter]

Problem

The daemon PR (#1436) replaced RotatingFileHandler with plain FileHandler in logging_config.py to avoid a theoretical race when forkserver workers rotate the same file. However, this removed the 10 MiB × 20 backup size cap entirely.

Blueprints running cameras + LCM at 30 fps write ~100 MB/min of JSON logs. After 5-10 minutes the log file grows to 500 MB–1 GB, triggering the OOM killer and crashing the entire machine. Multiple people have reported this on current dev.

Solution

Restore RotatingFileHandler with the original limits (10 MiB per file, 20 backups = 200 MiB cap). Both the main setup_logger() handler and the set_run_log_dir() migration handler are fixed.

The forkserver rotation race (multiple workers rotating the same file) can theoretically lose a few interleaved log lines, but this never caused issues in practice. Unbounded growth is a production-breaking OOM.

Changes:

• setup_logger(): FileHandler → RotatingFileHandler(maxBytes=10MiB, backupCount=20)
• set_run_log_dir(): migrated handlers also use RotatingFileHandler with same limits

Breaking Changes

None. Restores pre-#1436 behavior.

How to Test

cd /home/ubuntu/dimos
git fetch origin && git checkout fix/logging-oom-unbounded-file-handler
source .venv/bin/activate
# Run any blueprint with camera streams for >5 minutes — should no longer OOM
dimos run unitree-go2-basic --simulation
# Check log files stay bounded:
ls -lh ~/.local/state/dimos/logs/*/main.jsonl*

Contributor License Agreement

• I have read and approved the CLA

[greptile-apps]

Greptile Summary

This PR restores RotatingFileHandler (10 MiB per file, 20 backups = 200 MiB cap) in logging_config.py, reverting the FileHandler change from #1436 that eliminated the size cap and caused OOM crashes on resource-constrained devices running camera/LCM workloads at high log volumes (~100 MB/min).

Changes:

• setup_logger() (line 287-293): Replaces logging.FileHandler with logging.handlers.RotatingFileHandler(maxBytes=10 MiB, backupCount=20) and updates the comment to explicitly document the multi-process trade-off.
• set_run_log_dir() (line 65-71): Handler-migration path similarly creates RotatingFileHandler instances when re-pointing loggers to a new run directory.

The PR correctly bounds total disk usage to 200 MiB, which is the critical property needed to prevent OOM on production devices. The known architectural issue (multiple forkserver workers holding independent handler instances to the same file) is acknowledged in code comments as an acceptable trade-off.

Confidence Score: 5/5

• Safe to merge — correctly bounds disk usage and restores verified pre-regression behavior.
• This PR is a minimal, targeted revert of a known regression (feat(cli): daemon mode, stop, status, per-run logs (DIM-681, DIM-682, DIM-684, DIM-685) #1436) that caused production-breaking OOM crashes. The change is straightforward and correct: restoring RotatingFileHandler with appropriate size limits (10 MiB × 20 backups) in both handler creation paths. The architectural issue (multi-handler rotation race) is acknowledged in code comments and is an existing design pattern, not a new regression introduced by this PR. No logic errors, security issues, or correctness problems were found.
• No files require special attention beyond the single changed file.

_{Last reviewed commit: e600aa4}