Flushing preference cache with killall cfprefsd causing excessive wake ups on OS X 10.9.5

Question

My search on the webs shows that the terminate signal triggers cfprefsd daemons to reread all plist files. see here

When killall cfprefsd is executed the system freezes (showing the dreaded beach ball) until it completely has restarted the daemons (which can take 1-5 minutes on my system). On another Macbook (running 10.9.4) I don't observe this problem when running sudo killall cfprefsd.

This is what I find in the logs. Any ideas what can cause the excessive wake ups? Where do I look to find the problem causing this?

13-3-'15 11:30:36.063 AM sudo[54484]:     root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/killall cfprefsd
13-3-'15 11:31:28.000 AM kernel[0]: process who[54487] caught causing excessive wakeups. Observed wakeups rate (per sec): 864; Maximum permitted wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime number of wakeups: 45001
13-3-'15 11:31:28.000 AM kernel[0]: process cfprefsd[54488] caught causing excessive wakeups. Observed wakeups rate (per sec): 864; Maximum permitted wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime number of wakeups: 45001
13-3-'15 11:31:28.000 AM kernel[0]: process cfprefsd[54489] caught causing excessive wakeups. Observed wakeups rate (per sec): 864; Maximum permitted wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime number of wakeups: 45001

PS I have a suspicion one or more plist could be corrupted. How do I find out which?

UPDATE Mar 15, 2015:

I have run a couple of cfprefsd restarts using kill -15 <pid> (I have 2: root and myself). While in the past both seems to get caught with excessive wake ups (being terminated simultaneously), in my testing it seems to only apply to the one for root. So I can compare timestamps in records from fs_usage:

while the system freezes:

13:33:00.015    exit                                                    0.000054    cfprefsd.2656406
13:33:05.007    open    F=17    (R_____)/usr/sbin/cfprefsd                              0.000035    appProtd.1953
13:33:56.982    posix_spawn     /usr/sbin/cfprefsd                                                        5 1.9758   W  launchd.2656433
13:34:48.866    stat64          /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation   0.000012    cfprefsd.2656433

without any freezes:

13:35:30.124    exit                                                    0.000076    cfprefsd.2656806
13:35:31.790    open    F=17    (R_____)/usr/sbin/cfprefsd                              0.000029    appProtd.1953               
13:35:31.791    posix_spawn     /usr/sbin/cfprefsd                              0.000728 W  launchd.2657306
13:35:31.791    stat64          /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation   0.000014    cfprefsd.2657306

Looks like there is an issue with launchd creating the new cfprefsd process in a timely manner and starting the process, as during this interval the system freezes (note CPU is almost idle during this interval)

Answer 1

I don't know the answer, but I can make several troubleshooting suggestions:

• Don't worry about the "excessive wakeups" messages; AIUI those just indicate the process is using more kernel services than "usual", and don't necessarily indicate an actual problem (1, 2).
• Rather than killing all of the cfprefd processes at once, try killing them one at a time and see which one is causing the hang. You can use ps -ax -Ouser | grep [c]fprefsd to get a list of cfprefsd processes, then kill them by process ID with sudo kill <PID>.
• As you restart the cfprefsd processes, use sudo fs_usage | grep cfprefsd to watch what files they're accessing. Look for files accessed just before, during, or just after a hang as possible suspects.
• You can check the .plist files for format integrity with plutil -lint (e.g. sudo plutil -lint /Library/Preferences/*.plist). Note that this only checks the property list format integrity, not the information stored in the property list. Also, cfprefsd will normally fix (/discard & replace) corrupted files itself, so I doubt this'll turn anything up.
• Check the .plist files' permissions, flags, etc with e.g. ls -leO@ /Library/Preferences. For instance, if one of the files is locked (the "uchg" flag), or one of your user preferences is owned by a different user, it might cause odd effects.
• You can try removing possibly problematic files by e.g. moving them to your desktop (I'd make a backup of the entire relevant Preferences folder first!), and see what effect that has. When you're done experimenting with this, restore the back of the Preferences folder so you don't forget to restore any of the files you've messed with.