configd: Fixing High CPU Usage Problems with the configd Process in Mac OS X
configd is a system configuration daemon that runs behind Mac OS X, most users will never notice or see the core OS X process running in the background of their Macs. With that said, configd can sometimes act up and cause unusual CPU spikes and fan activity making your Mac sound like a wind tunnel. Odd configd behavior is easily diagnosed by launching Activity Monitor, sorting by the “% CPU” option, and seeing the ‘configd’ root user process sitting at the top taking up somewhere between 20-95% CPU. If that behavior lasts for a minute or so it’s usually not a big deal, temporary spikes can be normal so just let it run and ignore it, but there are times where configd can go inexplicably errant and it’ll sit around 50% CPU utilization or more for hours for no obvious reason – that is what we’re looking to resolve here.
Resolve configd High CPU Usage with Force Relaunch via Terminal
We’re going to forcibly relaunch configd by giving it a swift kick in the pants using the all-powerful ‘killall’ command. Because configd is a system process, it will instantly relaunch once it has been killed, and in every instance where configd is going crazy with processor utilization this trick solves the problem.
Launch Terminal (sitting within /Applications/Utilities/ as usual) and type the following command:
sudo killall configd
You’ll need to enter an administrator password to execute the command as super user, thus the sudo prefix. Running the command without sudo is ineffective because the process is owned by root (super user).
If you kept Activity Monitor open and sorted by CPU, you’ll find ‘configd’ disappears and when it relaunches it’s no longer sitting at the top of the list and no longer eating up inordinate amounts of CPU. Searching for the process should now find it consuming somewhere between 0% and 1% of CPU.
If you still have problems with configd after using the killall command, jump to the bottom of this article to learn more about troubleshooting configd issues.
Dealing with configd without Terminal
If you aren’t comfortable with the command line, there are two other options:
- Quit all running Mac applications, which you can do manually or by using this self-made app to quit everything in OS X
- Reboot the Mac
Rebooting the Mac has the same effect as killing the configd process directly, though it’s obviously a bit more intrusive to your workflow. Quitting every application can help if the configd error is caused by an apps errant behavior, more on that in a moment.
Diagnosing specific configd problems and learning about configd
Apple officially describes configd as follows:
The configd daemon is responsible for many configuration aspects of the local system. configd maintains data reflecting the desired and current state of the system, provides notifications to applications when this data changes, and hosts a number of configuration agents in the form of loadable bundles.
That excerpt is taken from the manual page on configd, which can be accessed by typing the following into terminal:
You can read that directly on your Mac through the command line, or through the web using the Developer Library link here.
If you want to attempt to diagnose why configd went crazy in the first place, you can look around in the following two locations for configd bundles and plist files, which may provide some hints as to what is going wrong and why:
Another option is to choose to re-run configd in verbose mode with the following command:
sudo /usr/libexec/configd -v
This will export verbose information to the OS X System Console, which can be read either from the Console app or through the command line as well. Comparing that information to what is found in the aforementioned system directories can be very helpful in diagnosing a precise cause.
General experience has shown that some apps and processes cause configd issues more often than others, some of which may include Java and Java based services like CrashPlan, certain printers where there are unresolved printing errors, and improper network configurations where a network connection is repeatedly attempting and failing. This is why sometimes quitting all apps is effective at resolving the issue, because it may end the failing repetition which is causing configd to go haywire, and in some cases where killing configd doesn’t solve the problem then removing the culprits plist file can resolve the issue once and for all. Your individual experiences and results may vary.