121 votos

proceso de distnotado desbocado

A veces veo un distnoted de repente se pone en marcha y consume el 100% de la CPU (en un núcleo) y una tonelada de memoria, a menudo en torno a 1,5G o así. Esto ocurre varias veces al día, desde hace un mes más o menos.

La línea de comandos es /usr/sbin/distnoted agent y es iniciado por launchd Ninguno de los dos ayuda mucho. Por lo general, ha estado funcionando entre 4 y 24 horas antes de que se ponga a girar y se pegue a la CPU.

Las búsquedas en la web dicen distnoted gestiona la entrega de notificaciones, y muchas otras personas informan del mismo problema, pero todavía no he encontrado una solución. Algunas personas encuentran que cerrar una aplicación culpable (por ejemplo, Skype) lo detiene, pero todavía no he encontrado un culpable en mi máquina. Por lo general, sólo ejecuto unas pocas aplicaciones: Emacs (24.2 de Homebrew), Firefox, Adium y Dash.

Estoy en Mavericks en un MBP Retina de 13" de finales de 2012. ¡Gracias de antemano!

Actualización:

He encendido distnoted en el registro del sistema tocando /var/log/do_dnserver_log pero no ayuda mucho. Veo líneas como estas (uid 501 soy yo, 89 no he encontrado todavía):

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.

También he corrido sudo dtruss -p PID en una hilera de distnoted proceso, y arroja líneas como esta:

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
...

0 votos

Sólo estoy pescando aquí, pero por cualquier cambio están todos corriendo flujo ? Para mí, parecen estar relacionados. Si salgo de flux cuando emacs se vuelve loco, emacs se bloquea o vuelve a la normalidad. No estoy seguro de si esto es una casualidad (sólo me ha pasado dos veces), pero si todo el mundo lo está usando, puede que haya algo en ello.

0 votos

No estoy ejecutando el flujo, pero tal vez otros son.

0 votos

aquaemacs hace que este proceso se me vuelva loco.

33voto

Don Tillman Puntos 311

Yo también he visto esto. Emacs 24.3.1, Mavericks 10.9.

He comprobado que el proceso de distnoted se calma en cuestión de segundos después de salir de Emacs.

He archivado un error de Emacs aquí: http://permalink.gmane.org/gmane.emacs.bugs/80836

2 votos

También se ve con Emacs v23.4.1.

1 votos

Lo mismo digo. Nunca imaginé que fuera causado por Emacs. Gracias

1 votos

Para mí, he estado teniendo el problema inverso - Emacs comienza a utilizar toda la CPU, y matando a mi usuario distnoted despeja el problema temporalmente. En este caso, mirando el proceso de Emacs veo un montón de hilos - no originados por Emacs - todos esperando en la cola/mutex de com.apple.Root.default-overcommit-priority (ejecuta lldb, "process attach --pid <pid>", y luego "thread backtrace all" para verlos todos)

25voto

Real Definition Puntos 11

Resumen de la OP : Esta fue una gran herramienta para la depuración. Originalmente me indicó que Spotlight reindexara el sistema de archivos, pero reduje las cosas que puede indexar y seguí viendo el problema. Terminé configurando un trabajo cron para matar a distnoted regularmente. Ver la respuesta más abajo.


Puedes depurar distnoted creando el archivo /var/log/do_dnserver_log Esto hace que el CFNotificationCenter servidor ( distnoted ) para registrar información sobre todas las notificaciones en el registro del sistema.

Yo empezaría por ahí, reiniciaría y miraría el registro del sistema cuando la CPU se dispare. Esto debería ser el culpable fácilmente.

Más información CFNotificationCenter La depuración se puede encontrar en los documentos oficiales para desarrolladores aquí: Nota técnica TN2124 > CFNotificationCenter

0 votos

gracias buena idea, ahora lo he hecho. no veo ninguna entrada distnoted en /var/log/system.log pero tampoco ha girado desde que empecé el registro. crucemos los dedos.

0 votos

Ahora estoy viendo líneas de registro distnoted, pero no son demasiado útiles. suspiro. ejemplo: 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

0 votos

Intenta adjuntar DTrace script a ese proceso y ver qué hace realmente, empieza con sudo dtruss -p PID y ver qué syscalls intenta hacer realmente el proceso y si hay alguno fallido (el estado no es 0).

23voto

user68323 Puntos 246

Sé que llego tarde a la fiesta, pero se trata de una fuga de memoria específica de Cocoa emacs en Mavericks que se corrige en el tronco. Por ahora hay un parche que puede utilizar para construir emacs 24.3 con sólo la solución.

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


1 votos

He actualizado a una compilación nocturna de Emacs para Mac OS X (en marzo) y sigo teniendo el problema. Parece que ocurre si creo una sesión interactiva para R o Clojure (lenguajes de programación). El proceso distnoted subirá lentamente a GB de RAM y lo liberará tan pronto como salgo de Emacs.

0 votos

El mismo problema que mencionó @mattrepl.

1 votos

Homebrew parece haber integrado este parche. Así que brew reinstall emacs --cocoa --with-gnutls puede arreglar el problema también. También se supone que se solucionará en la versión 24.4, pero aún no ha llegado a la versión estable.

8voto

ryan Puntos 459

Me rendí y tomé el enfoque del mazo: matarlo automáticamente, cada minuto. suspiro.

puse esto en ~/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>

y luego lo instalamos con launchctl load ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist .

1 votos

El enfoque de Michael Rourke a continuación es un toque más limpio, ya que sólo mata disnoted cuando comienza a comer cpu.

0 votos

@mike pero el enfoque de Michael Rourke no se ocupa de los casos en los que disnoted se está comiendo la RAM.

0 votos

@Cœur - Sí. No he experimentado ningún problema con que disnoted se coma la RAM. ¿Ha sido un problema que hayas visto?

4voto

Brainy Puntos 6

He estado haciendo diferentes combinaciones de personalizaciones de stripping para acotar este comportamiento; creo que es el modo comint. En 10.9 con emacs 24.3.1 desde homebrew (o desde emacsforosx) la fuga de distnoted + emacs (ambos aumentan lentamente el consumo de memoria) ocurrirá con un buffer de modo shell abierto. No lo hará si sólo visitas archivos.

Sólo quería anotarlo aquí, gmane parece estar caído y sigo encontrando esta discusión en mi búsqueda dos veces por semana de seguimientos a este tema.

0 votos

gracias! en realidad podría estar viendo lo mismo. pensé que castrar spotlight (la respuesta aceptada) había funcionado para mí, pero todavía estoy viendo distnoteds fugitivos después de todo. gracias de nuevo por la pista, puedo seguir esto y depurar más también.

0 votos

Creo que es algo que tiene que ver con mi proceso de Emacs también. distnoted se calmó justo después de que maté a Emacs. Tengo server.el, edit-server.el y un shell de Python funcionando en todo momento, para que conste.

0 votos

¡Viendo lo mismo! La culpa es de Emacs.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X