Parfois, je vois un distnoted
processus 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 distnoted
connexion 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 distnoted
processus 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éponses:
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 leCFNotificationCenter
serveur (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
CFNotificationCenter
débogage sont disponibles dans la documentation officielle pour les développeurs ici: Note technique TN2124> CFNotificationCenterla source
/var/log/system.log
, mais il n'a pas non plus filé depuis que j'ai commencé la journalisation. doigts croisés.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
sudo dtruss -p PID
et voyez quels appels système le processus essaie réellement de faire et s’il ya des échecs (l’état n’est pas à 0).strace
, mais je ne savais pasdtruss
. Je vais certainement essayer la prochaine fois. les pids ne sont que le processus correspondant, et les seuls uids sont moi et_appserveradm
un utilisateur système intégré dont je ne connais pas grand chose.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
la source
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
la source
brew reinstall emacs --cocoa --with-gnutls
peut résoudre le problème aussi. Il devrait également être corrigé dans la version 24.4, mais cela n’a pas encore été stable.top
) et tuer -9 emacs ne fonctionnait pas, mais après avoir tué -HUP, Emacs désapprouvé a répondu à la mise à mort.J'ai les mêmes problèmes avec
distnoted
El 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:Le script est exécuté depuis cron toutes les minutes avec cette ligne dans crontab:
En pratique, le script tue
distnoted
une ou deux fois par jour, généralement après lebackupd
démarrage.Pour ceux qui ne maîtrisent pas le shell OS X (ligne de commande), le script suivant installe à la fois le
checkdistnoted
script et l'entrée crontab:Vous devez enregistrer ce qui précède
install_checkdistnoted.sh
sur votre bureau, puis exécuterApplications/Utilities/Terminal
et saisir:Si cela fonctionne pleinement, la confirmation de chacune des étapes sera imprimée. Le script ne remplacera pas un
checkdistnoted
script existant ou une entrée de crontab.la source
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
:et ensuite installé avec
launchctl load ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist
.la source
disnoted
est en train de manger RAM.disnoted
mangeait 63 Go de RAM sur mon High Sierra hier. Même Ryan, dans sa question, affirme que le processus a été une perte de mémoire .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.
la source
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)
la source
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
distnoted
processus sont sortis. Les autres coupables identifiés sont Emacs et iTunes.la source
Pour ce que cela vaut, j'ai pu résoudre ce problème en désactivant mon logiciel anti-virus.
la source
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é.
la source
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 distnoted
toutes 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/file
ne 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.
la source
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
distonted
processus 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
distnoted
nous laisser savoir ce qui se passe.la source
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.
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.
Je ne sais pas pourquoi cela se produit…
la source
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.
la source
distnoted
comme ConorR l'a mentionné (et corrigé plus tard, merci!), Il est nécessaire de démarrer OSX (10.9.5 dans mon cas).