Environment
- ZimaOS v1.6.2, kernel 6.18.9
- Intel i5-3570K (4 cores), 7.5 GB RAM, 10 GB swap
- ~38 Docker containers; several NTFS drives mounted via ntfs-3g
Summary
After a large local file copy (~67 GB, ~749,000 files between two mounted drives), the two file services icewhale-files.service and icewhale-files-backup.service ballooned to ~6 GB RAM combined. On a 7.5 GB box this exhausted RAM, drove swap to ~98%, and triggered a hard-reset reboot loop (~every 9–10 min). No thermal or disk issue (CPU 45 °C, filesystems/RAID healthy, no OOM/panic logged — consistent with a watchdog reset from I/O stall).
Symptom — journalctl --list-boots
16:02→16:12 16:13→16:22 16:23→16:32 16:33→16:42 16:44→16:53 ← ~9–10 min each
16:55→ (24+ min, stable) ← after masking the services
Root cause
icewhale-files* appear to index/process every file on mounted drives with no memory cap; memory use scaled with file count. ps showed icewhale-files at 700 MB–2.4 GB resident, the rest paged into swap. The on-disk files.db index is only 24 MB, so the bloat is in-memory, not DB size.
Memory before/after
During loop: swap 88–98% used, <400 MB RAM free, top proc icewhale-files 2.4 GB
After mask: swap 2.4 GB, 4.5 GB RAM free, top proc ~80 MB
Workaround
sudo systemctl stop icewhale-files.service icewhale-files-backup.service
sudo systemctl mask icewhale-files.service icewhale-files-backup.service
Frees ~6 GB; stable since. Trade-off: the ZimaOS “Files” web app is disabled (SMB/other access unaffected).
Suggested fix
Add a systemd MemoryMax= cap to these services; paginate the index instead of loading the whole file set into memory; and/or add a UI toggle to disable the Files indexer on low-RAM/headless setups.