Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

Sometimes I see a distnoted process suddenly spin up and chew up 100% CPU (on one core) and a ton of memory, often in the neighborhood of 1.5G or so. This happens a few times a day, starting a month or so ago.

The command line is /usr/sbin/distnoted agent, and it's started by launchd, neither of which help much. It's usually been running for somewhere between 4h and 24h before it spins up and pegs the CPU.

Web searches say distnoted manages notification delivery, and lots of other people report the same problem with it, but I haven't yet found a fix. Some people find that closing a culprit application (e.g. Skype) stops it, but I haven't found a culprit on my machine yet. I'm usually only running a few apps: Emacs (24.2 from Homebrew), Firefox, Adium, and Dash.

I'm on Mavericks on a late 2012 13" Retina MBP. Thanks in advance!

Update:

I've turned on distnoted logging in the system log by touching /var/log/do_dnserver_log, but it doesn't help much. I see lines like these (uid 501 is me, 89 I haven't found yet):

distnoted[80011]: # distnote server agent  absolute time: 48754.144787848   civil time: Wed Nov 20 10:52:03 2013   pid: 80011 uid: 501  root: no
distnoted[20]: # distnote server daemon  absolute time: 2.808112262   civil time: Tue Nov 19 09:52:24 2013   pid: 20 uid: 0  root: yes
distnoted[444]: # distnote server agent  absolute time: 16.656997509   civil time: Tue Nov 19 09:52:38 2013   pid: 444 uid: 501  root: no
distnoted[1271]: # distnote server agent  absolute time: 52.518265717   civil time: Tue Nov 19 09:53:14 2013   pid: 1271 uid: 89  root: no
distnoted[689]: Interruption - exiting now.

I've also run sudo dtruss -p PID on a spun-up distnoted process, and it spews lines like this:

kevent64(0x3, 0x7FFF7C3FD130, 0x1)       = 1 0
workq_kernreturn(0x20, 0x0, 0x1)         = 0 0
workq_kernreturn(0x20, 0x0, 0x1)         = 0 0
kevent64(0x3, 0x7FFF7C3FD130, 0x1)       = 1 0
workq_kernreturn(0x20, 0x0, 0x1)         = 0 0
workq_kernreturn(0x20, 0x0, 0x1)         = 0 0
kevent64(0x3, 0x7FFF7C3FD130, 0x1)       = 1 0
workq_kernreturn(0x20, 0x0, 0x1)         = 0 0
__disable_threadsignal(0x1, 0x0, 0x0)    = 0 0
__disable_threadsignal(0x1, 0x0, 0x0)    = 0 0
__disable_threadsignal(0x1, 0x0, 0x0)    = 0 0
kevent64(0x3, 0x7FFF7C3FD130, 0x1)       = 1 0
workq_kernreturn(0x20, 0x0, 0x1)         = 0 0
...
share|improve this question
    
Just fishing here, but by any change are you all running flux? For me, they seem to be related. If I quit flux when emacs goes berserk, emacs either crashes or returns to normal. I'm not sure if this a fluke (only happened twice), but if everyone's running it, there might be something to it. –  user64563 Dec 10 '13 at 22:28
    
i'm not running flux, but maybe others are. –  ryan Dec 10 '13 at 23:47
    
aquaemacs causes this process to flip out on me. –  marathon Mar 22 at 17:21
    
I had a very similar problem (possibly the same problem) and my problem went away with the 10.9.4 OS update. –  Chris Quenelle Jul 30 at 3:12
    
Noticed this today. The culprit was the OS X (10.9) Google Drive app (1.17.7290.4094). First time I've seen this. –  jordanpg Sep 10 at 22:25

8 Answers 8

up vote 10 down vote accepted

Summary from the OP: this was a great tool for debugging. it originally pointed me to Spotlight reindexing the filesystem, but I narrowed down the things it's allowed to index, and I still saw the problem. I ended up setting up a cron job to kill distnoted regularly. See answer farther down.


You can debug distnoted by creating the file /var/log/do_dnserver_log This causes the CFNotificationCenter server (distnoted) to record information about all notifications to the system log.

I would start there, reboot and look at the system log when the CPU spikes up. This should out the culprit easily.

More info on CFNotificationCenter debugging can be found in official developer docs here: https://developer.apple.com/library/mac/technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECCFNOTIFICATION

share|improve this answer
    
thanks! good call, i've now done that. i'm not seeing any distnoted entries in /var/log/system.log, but it also hasn't spun up since i started the logging. fingers crossed. –  ryan Nov 22 '13 at 18:52
    
i am seeing distnoted log lines now, but they're not too useful. sigh. example: Nov 23 07:56:15 hell.local distnoted[2644]: # distnote server agent absolute time: 77.445654904 civil time: Sat Nov 23 07:56:15 2013 pid: 2644 uid: 89 root: no –  ryan Nov 24 '13 at 22:19
    
Try to attach DTrace script to that process and see what it actually does, start with sudo dtruss -p PID and see what syscalls does the process actually try to do and if there are any failed ones (status is not 0). –  Temikus Nov 25 '13 at 12:06
    
Also, what is the UID 89 on your system? Does the UID in notifications change? Does the pid 2644 correspond to distnoted or another process? –  Temikus Nov 25 '13 at 13:47
    
thanks for the ideas! i'm familiar with strace, but i didn't know about dtruss. i'll definitely try that next time. the pids are just the corresponding distnoted process, and the only uids are me and _appserveradm, a built-in system user i don't know much about. –  ryan Nov 26 '13 at 15:55

I've seen this too. Emacs 24.3.1, Mavericks 10.9.

I've found that the distnoted process calms down within seconds after I quit out of Emacs.

I've filed an Emacs bug here: http://permalink.gmane.org/gmane.emacs.bugs/80836

share|improve this answer
2  
Also seen with Emacs v23.4.1. –  WilliamKF Mar 15 at 0:23
1  
Same here. Never imagined it was caused by Emacs! Thanks –  yoplait Jun 3 at 7:12
1  
For me, I've been having the converse problem - Emacs starts using all CPU, and killing my user's distnoted clears the problem temporarily. In this case, looking at the Emacs process I see a lot of threads - non-Emacs originated ones - all waiting on the com.apple.root.default-overcommit-priority queue/mutex (run lldb, "process attach --pid <pid>", and then "thread backtrace all" to see them all) –  jrg Jun 23 at 14:28
    
and this is an interesting read on what all those threads actually are: newosxbook.com/articles/GCD.html (my killing distnoted might be a 'magic feather', and not the thing that brings it back to normal) –  jrg Jun 24 at 11:51

I know I'm late to the party but this is a memory leak specific to Cocoa emacs on Mavericks that is fixed in the trunk. For now there is a patch you can use to build emacs 24.3 with just the fix.

https://gist.github.com/anonymous/8553178


share|improve this answer
    
great find, thanks! –  ryan Jan 22 at 23:13
1  
I updated to a nightly build from the Emacs for Mac OS X (in March) and still have the problem. It appears to happen if I create an interactive session for R or Clojure (programming languages). The distnoted process will slowly climb to GB of RAM and will free it as soon as I exit Emacs. –  mattrepl May 21 at 22:57
    
Same problem that @mattrepl mentioned. –  user815423426 Jun 3 at 18:39
    
Right on, thanks! –  kcbanner Jul 15 at 21:06
1  
Homebrew appears to have integrated this patch. So brew reinstall emacs --cocoa --with-gnutls may fix the problem too. It's also supposed to be fixed in 24.4 but that hasn't hit stable yet. –  mblakele Aug 6 at 20:17

i gave up and took the sledgehammer approach: kill it automatically, every minute. sigh.

i put this in ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist:

<plist version="1.0">
<dict>
  <key>Label</key>
  <string>org.snarfed.pkill_distnoted</string>
  <key>ProgramArguments</key>
  <array>
    <string>pkill</string>
    <string>-KILL</string>
    <string>-f</string>
    <string>distnoted</string>
  </array>
  <key>StartInterval</key>
  <integer>60</integer>  <!-- every minute -->
</dict>
</plist>

and then installed it with launchctl load ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist.

share|improve this answer

I've been doing different combinations of stripping customizations in order to narrow down this behavior; I think it's comint mode. On 10.9 with emacs 24.3.1 from homebrew (or from emacsforosx) the distnoted + emacs leak (they both slowly increase in memory consumption) will happen with one shell-mode buffer open. It won't if you just visit files.

Just wanted to note it here, gmane appears to be down and I keep finding this discussion on my twice weekly search for followups to this issue.

share|improve this answer
    
thanks! i might actually be seeing the same thing. i thought neutering spotlight (the accepted answer) had worked for me, but i'm still seeing runaway distnoteds after all. thanks again for the lead, i may follow this and debug more too. –  ryan Dec 12 '13 at 18:09
    
I believe it's something to deal with my Emacs process as well. distnoted calmed right down after I killed off Emacs. I have server.el, edit-server.el and a python shell running at all times for the record. –  Lester Cheung Dec 13 '13 at 6:49
    
Seeing the same thing! Emacs to blame! –  justingordon Mar 25 at 2:56
    
I don't even know what comint mode is and I have the distnoted problem from emacs at times. So maybe no specific package is to blame. –  huyz Aug 29 at 19:29

For what it's worth, I was able to fix this problem by disabling my anti-virus software.

share|improve this answer

This happened to me as well, distnoted was going crazy. After closing a bunch of applications, nothing helped.

Then I noticed one of those 'Report to Apple' dialogs from a crashed Python process had been left open all night.

Though it could just be coincidence, after closing the dialog the distnoted process calmed down.

share|improve this answer

This happens to me to, a few times a day. I can't narrow it down to one specific app that makes it happen. My theory is that some sort of IPC is happening between distnoted and something else. I can see distnoted is processing incoming XML messages when it gets busy. I want to know what process is sending it messages when that happens. Is there any way to trace inter-process-communication in Mac OS X?

I have also created do_dnserver_log, but I'm not seeing any messages to the system log. Possibly it's wrapping, is there a log size limit that causes older messages to be purged?

Update: This seems to be fixed for me in MacOS 10.9.4. It was still happening in 10.9.3.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.