processus distancié emballé

Parfois, je vois un distnotedprocessus se mettre en marche soudainement et gruger 100% de l’UC (sur un cœur) et une tonne de mémoire, souvent au voisinage de 1,5 G environ. Cela se produit plusieurs fois par jour, il y a environ un mois.

La ligne de commande est /usr/sbin/distnoted agent, et elle est lancée par launchd, aucune de ces aides n’est très utile. Il fonctionne généralement entre 4h et 24h avant de tourner et de bloquer le processeur.

Selon les recherches sur le Web distnoted, la livraison des notifications est gérée, et de nombreuses autres personnes signalent le même problème, mais je n’ai pas encore trouvé de solution. Certaines personnes trouvent que la fermeture d'une application coupable (par exemple, Skype) l'arrête, mais je n'ai pas encore trouvé de coupable sur ma machine. En général, je ne lance que quelques applications: Emacs (24.2 de Homebrew), Firefox, Adium et Dash.

Je suis sur Mavericks pour un Retin MBP de 13 "à la fin de 2012. Merci d'avance!

Mise à jour:

J'ai activé la distnotedconnexion au journal système en touchant /var/log/do_dnserver_log, mais cela n'aide pas beaucoup. Je vois des lignes comme celles-ci (uid 501, c’est moi, 89 ans, je n’ai pas encore trouvé):

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.

J'ai également eu recours sudo dtruss -p PIDà un distnotedprocessus accéléré, et il crache des lignes comme celle-ci:

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

Résumé de l’opération : C’était un excellent outil de débogage. À l'origine, il m'indiquait que Spotlight réindexait le système de fichiers, mais j'ai réduit le nombre de choses qu'il est autorisé à indexer et j'ai toujours vu le problème. J'ai fini par configurer un travail cron pour tuer régulièrement Distnote. Voir la réponse plus bas.

Vous pouvez déboguer distnoted en créant le fichier. /var/log/do_dnserver_log Cela force le CFNotificationCenterserveur ( distnoted) à enregistrer des informations sur toutes les notifications dans le journal système.

Je voudrais commencer par là, redémarrer et regarder le journal du système lorsque le processeur monte en puissance. Cela devrait facilement sortir du coupable.

Plus d'informations sur le CFNotificationCenterdébogage sont disponibles dans la documentation officielle pour les développeurs ici: Note technique TN2124> CFNotificationCenter

J'ai vu ça aussi. Emacs 24.3.1, Mavericks 10.9.

J'ai constaté que le processus de distribution s'arrêtait quelques secondes après mon départ d'Emacs.

J'ai déposé un bogue Emacs ici: http://permalink.gmane.org/gmane.emacs.bugs/80836

Je sais que je suis en retard à la fête, mais il s'agit d'une fuite de mémoire spécifique à Cocoa emacs sur Mavericks qui est corrigée dans le coffre. Pour le moment, il existe un correctif que vous pouvez utiliser pour compiler emacs 24.3 uniquement avec le correctif.

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

J'ai les mêmes problèmes avec distnotedEl Capitan depuis quelque temps. Ma solution n'est pas aussi dure que de la tuer régulièrement, mais plutôt de vérifier si elle devient incontrôlable (utilisation intensive du processeur), puis de la tuer. J'utilise ce script:

#!/bin/sh
#
# check for runaway distnoted, kill if necessary
#
PATH=/bin:/usr/bin
export PATH

ps -reo '%cpu,uid,pid,command' | 
    awk -v UID=$UID '
    /distnoted agent$/ && $1 > 100.0 && $2 == UID { 
        system("kill -9 " $3) 
    }
    '

Le script est exécuté depuis cron toutes les minutes avec cette ligne dans crontab:

*   *  *   *  *   sh "$HOME/bin/checkdistnoted"

En pratique, le script tue distnotedune ou deux fois par jour, généralement après le backupddémarrage.

Pour ceux qui ne maîtrisent pas le shell OS X (ligne de commande), le script suivant installe à la fois le checkdistnotedscript et l'entrée crontab:

#!/bin/sh
#
# install $HOME/bin/checkdistnoted
# setup crontab to run every minute
# 
# MWR Apr 2016
#

INSTALLCMD=bin/checkdistnoted
cd "$HOME"
[ ! -d bin ] && mkdir bin
[ -f $INSTALLCMD ] || {
    cat > $INSTALLCMD <<-"!!"
    #!/bin/sh
    #
    # check for runaway distnoted, kill if necessary
    #

    PATH=/bin:/usr/bin
    export PATH

    ps -reo '%cpu,uid,pid,command' | 
        awk -v UID=$UID '
        /distnoted agent$/ && $1 >= 100.0 && $2 == UID { 
            # kill distnoted agent with >= 100% CPU and owned by me
            system("kill -9 " $3) 
        }
        '
!!
    chmod +x $INSTALLCMD 
    echo installed $INSTALLCMD
}

INSTALLCRON="# check for runaway distnoted every minute:
* * * * * sh \"\$HOME/$INSTALLCMD\""
crontab -l | grep -q '$HOME'/$INSTALLCMD || {
    crontab -l > mycron
    echo "$INSTALLCRON" >> mycron
    crontab mycron
    rm mycron
    echo updated crontab
}

Vous devez enregistrer ce qui précède install_checkdistnoted.shsur votre bureau, puis exécuter Applications/Utilities/Terminalet saisir:

cd Desktop
sh install_checkdistnoted.sh 

Si cela fonctionne pleinement, la confirmation de chacune des étapes sera imprimée. Le script ne remplacera pas un checkdistnotedscript existant ou une entrée de crontab.

J'ai abandonné et pris l'approche sledgehammer: tuez-le automatiquement, chaque minute. soupir.

je mets ceci dans ~/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>

et ensuite installé avec launchctl load ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist.

J'ai eu recours à différentes combinaisons de personnalisation pour supprimer ce comportement. Je pense que c'est le mode comint. Sur 10.9 avec emacs 24.3.1 de homebrew (ou d’emacsforosx), la fuite distnoted + emacs (la consommation de mémoire augmente lentement) se produira avec un tampon en mode shell ouvert. Ce ne sera pas si vous ne visitez que des fichiers.

Je voulais juste le noter ici, gmane semble être en panne et je continue à trouver cette discussion lors de ma recherche bimensuelle de suivis de cette question.

Je pense que je ne me souviens que de 2 occasions où distnoted est devenu fâcheux. À cette occasion, 2 d'entre eux se trouvaient au sommet de la liste des processeurs et l'un d'entre eux dépassait 400%. C'est arrivé peu de temps après être rentré au bureau et avoir branché deux écrans externes - dont l'un est alimenté par USB - j'ai supposé que cela pouvait être lié. Je n'ai rien fait d'autre pour essayer de résoudre le problème avant de retirer l'écran USB, ce qui a ramené la santé mentale instantanément. Et puis le rebrancher n'a abouti à aucun problème de répétition.

Ce qui prouve quoi? Aucune idée!

Je les branche des centaines de fois et c'est la première fois que je pensais que cela pouvait être lié. Et comme cela ne se produit pas à chaque fois que je les branche, cela pourrait alors avoir quelque chose à voir avec les connecter tous les deux trop rapidement l'un à la suite de l'autre, ou quelque chose de ce genre au hasard. Je pensais de toute façon que je partagerais au cas où d’autres personnes trouvent que cela a quelque chose à voir avec le branchement de périphériques (s’il s’agit d’un écran externe)

Cela semble se produire lorsqu'une application utilise de manière erronée l'API de notification fournie par macOS. Dans mon cas, le coupable était iTerm2. Après l'avoir quitté, les distnotedprocessus sont sortis. Les autres coupables identifiés sont Emacs et iTunes.

Pour ce que cela vaut, j'ai pu résoudre ce problème en désactivant mon logiciel anti-virus.

Cela m'est arrivé aussi, Distnote devenait fou. Après la fermeture d'un tas d'applications, rien n'a aidé.

Ensuite, j'ai remarqué qu'une des boîtes de dialogue «Signaler à Apple» d'un processus Python bloqué était restée ouverte toute la nuit.

Bien que cela puisse être une simple coïncidence, après la fermeture du dialogue, le processus de distribution a été calmé.

J'ai rencontré un problème similaire avec distnote il y a quelques mois et je ne pouvais pas savoir pourquoi l'utilisation du processeur dépassait 100%. Enfin, j'ai ajouté une entrée à ma crontab killall distnotedtoutes les 2 minutes, ce qui a résolu mon problème.

Récemment, je rencontrais un problème avec Sublime Text où la saisie subl path/to/filene permettait pas d'ouvrir correctement le fichier dans l'éditeur Sublime. Un redémarrage de l'application a résolu le problème, mais cela a rapidement recommencé.

Après avoir déchiré mon cerveau sans fin, j'ai identifié le fait que je tuais un processus distnoted toutes les 2 minutes pour expliquer pourquoi la sous-commande avait mystérieusement cessé de fonctionner.

La conclusion: l’utilisation très élevée du processeur a peut-être été liée au sublime. Maintenant que sublime a été mis à jour, j'espère que ma conclusion est correcte, l'utilisation du processeur reste faible et que ma commande sublime fonctionne comme prévu maintenant que distnoted s'exécute à nouveau sans que ma crontab ne tue le processus toutes les 2 minutes.

J'ai aussi ce problème depuis assez longtemps, mais par intermittence. Apparemment, distnoted fait partie d'iTunes et a également causé des problèmes sous Windows . Lorsque j'ai tué iTunes (qui jouait une chanson), le distontedprocessus utilisant 400% de mon processeur (j'ai 4 cœurs) a cessé d'être un problème.

Donc, ma réponse, jusqu'à ce que je sache mieux, est de vous recommander de tuer iTunes et non de distnotednous laisser savoir ce qui se passe.

Je vois aussi distnoted aller en foin, dans mon cas, il semble lié à fontd. J'ai trois programmes en cours d'exécution, un pour _spotlight, un pour _distnote et un pour mon utilisateur.

distnoted   0,0 6:39,85 2   0   101 _distnote   0 bytes 0 bytes     No      -   No  No  No  0 bytes 0 bytes 64 bit
distnoted   0,0 0,05    2   0   642 _spotlight  0 bytes 0 bytes     Yes     -   No  No  No  0 bytes 0 bytes 64 bit
distnoted   82,1    1:19:38,30  49  1   353 nils    0 bytes 0 bytes     No      -   No  No  No  0 bytes 0 bytes 64 bit

Chaque fois que distnoted mange cpu (30-90%), fontworker et fontd mangent environ 30-60% cpu chacun. Dès que je tue fontd, distnoted et fontworker, mon utilisateur se calme. Tuer Fontworker ne fait rien. Après quelques minutes, lorsque fontd a redémarré et fonctionne depuis un moment, tout recommence.

fontworker  27,2    52,81   4   1   1073    nils    0 bytes 0 bytes     No      -   No  No  No  0 bytes 0 bytes 64 bit

fontd   32,6    1:07,41 6   0   1072    nils    0 bytes 0 bytes     No      -   No  No  No  0 bytes 0 bytes 64 bit

Je ne sais pas pourquoi cela se produit…

Peter Buckley a raison, je me trompe. Je déteste quand ça arrive.

Ne supprimez pas distnoted, le prochain démarrage ne sera pas amusant du tout.

faux> j'ai adopté une approche plus agressive
faux> 
faux> sudo mv / usr / sbin / distnoted /usr/bin/distnoted.unwanted
faux>
faux> Ceci est une machine de travail et je n'ai aucun intérêt à synchroniser avec iTunes.