3

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)

Peter B
  • 31
  • 1
  • 1
  • 4
  • Why are you using `sudo` on the `killall cfprefsd` command? Generally you only want to restart your own instance of cfprefsd, which means you don't want `sudo`. – Gordon Davisson Mar 14 '15 at 13:47
  • It is part of script run by the company policy over which I have no control. Both daemons (root and mine) suffer from the excessive wake ups. – Peter B Mar 14 '15 at 15:33
  • I have compared cfprefsd checksum on both 10.9.4 and 10.9.5 and they are identical. So the different observed behaviour is likely not caused by a code upgrade. – Peter B Mar 14 '15 at 19:09

2 Answers2

2

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.
Gordon Davisson
  • 118,432
  • 16
  • 123
  • 151
  • Thanks Gordon, these tips are helpful in particular what excessive wake ups means. I have tried to kill them one by one, both seem to hang, but now that I have more ideas on how to nail down the problem I can further investigate. I am going to use `sudo fs_usage -w cfprefsd | tee -a cfprefsd_fs_usage.txt` which will give more information (and times) to find correlations when the system gets very active (causing it to 'freeze') and cfprefsd activity. I should note that some of the plists are controlled by corporate IT, will be interesting to see which one cause the problems! – Peter B Mar 15 '15 at 19:30
  • Looks like having fs_usage filter by cmd is not picking up the relaunched cfprefsd, your suggestion using to pipe it into `grep cfprefsd` is necessary... – Peter B Mar 15 '15 at 19:57
  • @PeterB If you supply a process name to `fs_usage`, it seems to only scan for matching processes when it starts -- as a result, it'll fail to notice the relaunched cfprefsd processes. – Gordon Davisson Mar 15 '15 at 20:11
  • I saw that! :-) I have updated my question, because adding a comment is limited in length. Hope that I follow the etiquette as I am new here. – Peter B Mar 16 '15 at 01:28
0

It turned out that I was running McAfee VirusScan version 9.7.0 which is for Yosemite. After downgrading to version 9.6.0 the observed problems of flushing cfprefsd went away.

Peter B
  • 31
  • 1
  • 1
  • 4