The Diagnostic Subsystem
macOS is a highly resilient operating system designed to automatically diagnose and recover from application hangs and kernel panics. At the center of this telemetry engine is the CoreSymptom daemon (symptomsd). This background process constantly monitors the operating system for signs of distress—such as a specific application repeatedly crashing, the Wi-Fi card experiencing excessive packet loss, or the CPU thermal throttling.
When the CoreSymptom daemon detects these anomalies, it logs the “symptoms” into a centralized SQLite database. This database is then queried by Apple’s diagnostic tools and by the operating system itself to dynamically adjust performance (for example, slowing down a runaway process to prevent the Mac from overheating).
However, if this telemetry database becomes corrupted—often due to an aggressive forced shutdown or a massive volume of rapid-fire crashes from a poorly coded third-party application—the symptomsd process will enter a panic loop. The daemon will consume 100% of your CPU attempting to read the corrupted database, your Mac’s fans will spin up to maximum speed, and the entire system will become sluggish. To resolve this runaway telemetry process, you must forcefully purge the CoreSymptom cache via the Terminal.
Locating the Symptom Caches
Because the CoreSymptom daemon monitors the entire system (including kernel-level hardware faults), its databases are not stored in your user profile. They are securely isolated in the root-level diagnostic directories.
Specifically, the data resides in /var/db/symptomsd/ and the system-wide logging directories.
Purging the Cache via Terminal
You must use the Terminal with elevated (sudo) privileges. Standard user accounts cannot terminate this daemon or delete its system-level files.
- Open the Terminal application.
- First, you must forcefully terminate the runaway daemon. This immediately stops the 100% CPU usage and releases the file locks on the corrupted SQLite databases:
sudo killall symptomsd
Press Enter, type your Mac’s administrator password (the characters will remain invisible), and press Enter again.
- Next, aggressively delete the primary database directory. We use the
-rfflag to recursively delete the folder contents without asking for confirmation:
sudo rm -rf /var/db/symptomsd/*
- Additionally, clear the secondary diagnostic event logs that the daemon might be attempting to parse:
sudo rm -rf /Library/Logs/DiagnosticReports/*symptoms*
Resetting the System Policy
The physical cache files are now gone, but the macOS System Configuration might still hold stale pointers to the broken database.
To ensure a completely clean slate, you should reset the daemon’s preference file:
sudo rm -f /Library/Preferences/com.apple.symptomsd.plist
The Recalibration
macOS relies heavily on launchd, the primary service manager. The moment you executed the killall symptomsd command, launchd detected that a critical system service had crashed and instantly respawned a fresh, uncorrupted instance of it in the background.
This new daemon initialized, looked for the /var/db/symptomsd/ database, realized it was empty, and generated a completely fresh, 0-byte SQLite file. The CPU usage will instantly drop back to a normal baseline (typically 0.01%), and the massive system lag will be permanently resolved. The Mac will seamlessly resume monitoring for hardware and software faults without the crippling overhead of a corrupted telemetry loop.