The original high-CPU behavior was not simply “normal indexing can run forever.” After a large transfer, searchd stayed at 100% CPU for hours—and some users reported multiple days—raising system temperature and forcing them to choose between stopping search or leaving the CPU busy.
IceWhale later gave a precise explanation: an occasional pagination-logic corner case could cause the long-running CPU problem. It was fixed/optimized in ZimaOS 1.3.2-beta2. The same update added search-engine folding after idle time, kept filename indexing accurate/real-time, and moved file-content indexing to midnight with lower resource usage. Current ZimaOS Search documentation has evolved further, with explicit throttling and much lower idle memory/service counts.
searchd dominating CPU after the transfer had already completed.Search Requires an Index
Zima-Giorgio initially explained that the Files search function needs to index files. That part was correct, but it did not explain why CPU stayed pegged for unusually long periods.
IceWhale Later Identified a Pagination-Logic Corner Case
On February 11, 2025, orca-zhang said the long CPU problem could occasionally be caused by a pagination-logic error and that the issue had been fixed and optimized in 1.3.2-beta2.
This is the strongest source conclusion and should replace the earlier vague “it is indexing” explanation.
1.3.2 Added Idle Search-Service Folding
IceWhale said that when search was not needed, searchd would be released after roughly three minutes of idle time, leaving only the lightweight zimaos-search service below 100 MB memory and around 0–1% CPU.
Content Indexing Was Moved to Midnight
The same reply separated two jobs:
- filename index — kept as accurate and real-time as possible;
- file-content index — delayed until midnight and run at low resource usage.
That distinction still exists in the current search architecture.
Current ZimaOS Search Adds Explicit Resource Limits
Current IceWhale documentation describes:
- real-time file-change monitoring and filename indexing;
- content indexing at midnight;
- maximum 100,000 documents per processing type/session;
- maximum five minutes processing time per type;
- write-barrier protection against CPU spikes;
- service/memory folding after inactivity.
Use the current ZimaOS Search architecture.
Search Could Be Disabled from ZimaOS 1.3.2
orca-zhang said the persistence added to /etc in 1.3.2 allowed users who did not need search to run:
systemctl disable zimaos-searchStopping/disabling search means Files search will report that the service is unavailable. Current users should first verify current search behavior before disabling a core service solely because of a historical bug.
The /dev/root “100% Full” Screenshot Was a Different Issue
Another participant noticed /dev/root showed 100% use and tried to enlarge it. IceWhale explained that this read-only SquashFS root representation is intentional for system integrity and should not be treated like a conventional writable root partition that needs free space.
Do not resize/delete ZimaOS system partitions because the SquashFS image reports full.
If Search Uses High CPU on Current ZimaOS
- confirm the system is on current stable ZimaOS;
- check whether a large file import just occurred;
- allow the documented indexing window to finish;
- monitor whether CPU falls after the service's idle period;
- collect current
zimaos-searchlogs if CPU remains high well beyond the expected window.
searchd High CPU FAQ
Was 100% CPU for multiple days considered normal?
No. IceWhale later identified a pagination-logic corner case and fixed it in 1.3.2-beta2.
When does current ZimaOS do content indexing?
Current documentation says content indexing is processed during off-peak hours at midnight, while filename changes are indexed in real time.
Does /dev/root at 100% mean the system disk is out of free space?
Not in the source case. IceWhale explained that the SquashFS system-root representation is intentionally read-only and expected to appear full.
