außer Kontrolle geratener Prozess

116

Manchmal sehe ich, wie sich ein distnotedProzess plötzlich dreht und 100% der CPU (auf einem Kern) und eine Tonne Speicher aufbaut, oft in der Nähe von 1,5 GB oder so. Dies geschieht einige Male am Tag, beginnend vor einem Monat oder so.

Die Kommandozeile ist /usr/sbin/distnoted agentund wird von launchdkeiner viel helfen. Es läuft normalerweise zwischen 4 und 24 Stunden, bevor es hochfährt und die CPU blockiert.

Laut Internetsuchen wird die distnotedZustellung von Benachrichtigungen verwaltet, und viele andere Personen berichten über das gleiche Problem, aber ich habe noch keine Lösung gefunden. Einige Leute finden, dass das Schließen einer Täteranwendung (z. B. Skype) diese beendet, aber ich habe noch keinen Täter auf meinem Computer gefunden. Ich verwende normalerweise nur ein paar Apps: Emacs (24.2 von Homebrew), Firefox, Adium und Dash.

Ich bin auf Mavericks auf einem 13 "Retina MBP Ende 2012. Vielen Dank im Voraus!

Aktualisieren:

Ich habe das distnotedAnmelden im Systemprotokoll durch Berühren von aktiviert /var/log/do_dnserver_log, aber es hilft nicht viel. Ich sehe Zeilen wie diese (UID 501 bin ich, 89 habe ich noch nicht gefunden):

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.

Ich habe auch sudo dtruss -p PIDeinen hochgezogenen distnotedProzess ausgeführt, der folgende Zeilen enthält:

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
...
Ryan
quelle
Fischen Sie nur hier, aber bei jeder Veränderung sind Sie alle im Fluss ? Für mich scheinen sie verwandt zu sein. Wenn ich den Fluss beende, wenn der Emacs wütend wird, stürzt der Emac entweder ab oder kehrt zum Normalzustand zurück. Ich bin mir nicht sicher, ob dies ein Zufall ist (nur zweimal), aber wenn es von allen ausgeführt wird, könnte etwas dran sein.
Ich lasse kein Flux laufen, aber vielleicht sind es andere.
Ryan
aquaemacs lässt diesen Prozess bei mir ausflippen.
Marathon
Ich hatte ein sehr ähnliches Problem (möglicherweise dasselbe Problem) und mein Problem ging mit dem 10.9.4 OS-Update weg.
Chris Quenelle
Heute bemerkt. Schuld daran war die Google Drive-App für OS X (10.9) (1.17.7290.4094). Zum ersten Mal habe ich das gesehen.
jordanpg

Antworten:

24

Zusammenfassung aus dem OP : Dies war ein großartiges Tool zum Debuggen. Ursprünglich wollte ich das Dateisystem in Spotlight neu indizieren, aber ich habe die Dinge, die indiziert werden dürfen, eingegrenzt, und ich habe immer noch das Problem gesehen. Am Ende habe ich einen Cronjob eingerichtet, um Distnoted regelmäßig zu töten. Siehe Antwort weiter unten.


Sie können einen bestimmten Fehler beheben, indem Sie eine Datei erstellen. /var/log/do_dnserver_log Dadurch zeichnet der CFNotificationCenterServer ( distnoted) Informationen zu allen Benachrichtigungen im Systemprotokoll auf.

Ich würde dort starten, neu starten und das Systemprotokoll anzeigen, wenn die CPU hochfährt. Dies sollte den Täter leicht herausfinden.

Weitere Informationen zum CFNotificationCenterDebuggen finden Sie in den offiziellen Entwicklerdokumenten hier: Technischer Hinweis TN2124> CFNotificationCenter

Temikus
quelle
Vielen Dank! Guter Anruf, das habe ich jetzt getan. Ich sehe keine distnoted Einträge in /var/log/system.log, aber es hat sich auch nicht gedreht, seit ich die Protokollierung gestartet habe. Daumen drücken.
Ryan
Ich sehe jetzt distnoted Protokollzeilen, aber sie sind nicht zu nützlich. Seufzer. Beispiel: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
Versuchen Sie, ein DTrace-Skript an diesen Prozess anzuhängen und zu sehen, was es tatsächlich tut. Beginnen Sie mit sudo dtruss -p PIDund sehen Sie, welche Systemaufrufe der Prozess tatsächlich versucht und ob es irgendwelche fehlgeschlagenen gibt (der Status ist nicht 0).
Temikus
Wie lautet die UID 89 auf Ihrem System? Ändert sich die UID in Benachrichtigungen? Entspricht die PID 2644 Distnoted oder einem anderen Prozess?
Temikus
danke für die ideen! Ich bin vertraut mit strace, aber ich wusste nicht dtruss. Ich werde es auf jeden Fall beim nächsten Mal versuchen. die pids sind nur der entsprechende distnoted Prozess, und die einzigen uids sind ich und _appserveradmein eingebauter Systembenutzer, über den ich nicht viel weiß.
Ryan
33

Ich habe das auch gesehen. Emacs 24.3.1, Mavericks 10.9.

Ich habe festgestellt, dass sich der distnotierte Prozess innerhalb von Sekunden nach dem Verlassen von Emacs beruhigt.

Ich habe hier einen Emacs-Fehler gemeldet: http://permalink.gmane.org/gmane.emacs.bugs/80836

Don Tillman
quelle
2
Auch mit Emacs v23.4.1 zu sehen.
WilliamKF
1
Hier gilt das gleiche. Ich hätte nie gedacht, dass es von Emacs verursacht wurde! Danke
Lionel Henry
1
Für mich hatte ich das gegenteilige Problem: Emacs nutzt nun die gesamte CPU, und durch das Beenden der Distnoted meines Benutzers wird das Problem vorübergehend behoben. In diesem Fall sehe ich beim Betrachten des Emacs-Prozesses viele Threads - nicht von Emacs stammende -, die alle auf die Warteschlange com.apple.root.default-overcommit-priority / mutex warten (führen Sie lldb aus, "process attach --pid <pid> "und dann" alle
zurückverfolgen
und dies ist eine interessante Lektüre darüber, was all diese Threads tatsächlich sind: newosxbook.com/articles/GCD.html (Mein Mord könnte eine 'magische Feder' sein und nicht das, was es wieder normal macht)
jrg
Auch mit Emacs v24.5 unter OS X 10.11.3 zu sehen
Michael
23

Ich weiß, dass ich zu spät zur Party komme, aber dies ist ein Speicherverlust, der speziell für Cocoa-Emacs auf Mavericks gilt und im Kofferraum behoben ist. Im Moment gibt es einen Patch, mit dem Sie Emacs 24.3 nur mit dem Fix erstellen können.

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


user68323
quelle
1
Ich habe auf einen nächtlichen Build von Emacs für Mac OS X (im März) aktualisiert und habe immer noch das Problem. Es scheint zu passieren, wenn ich eine interaktive Sitzung für R oder Clojure (Programmiersprachen) erstelle. Der distnoted-Prozess wird langsam auf GB RAM ansteigen und ihn freigeben, sobald ich Emacs beende.
Mattrepl
Dasselbe Problem, das @mattrepl erwähnt hat.
Amelio Vazquez-Reina
1
Homebrew scheint diesen Patch integriert zu haben. So brew reinstall emacs --cocoa --with-gnutlskann das Problem auch behoben werden. Es soll auch in 24.4 behoben sein, aber das ist noch nicht stabil.
mblakele
Habe gerade dieses Problem mit Emacs 24.5 erlebt (Fix sollte in 24.4 sein). In meinem Fall zeigte Emacs den sich drehenden Ball und distnoted beanspruchte fast 400% CPU (pro top) und das Töten von -9 Emacs funktionierte nicht, aber nach dem töten reagierten -HUP disnoted emacs auf den kill.
Michael
17

Ich habe seit distnotedeiniger Zeit die gleichen Probleme mit El Capitan. Meine Lösung ist nicht so hart wie das regelmäßige Beenden, sondern ich überprüfe, ob die Kontrolle verloren geht (hohe CPU-Auslastung), und beende sie dann. Ich benutze dieses Skript:

#!/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) 
    }
    '

Das Skript wird jede Minute von cron ausgeführt, wobei die folgende Zeile in crontab steht:

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

In der Praxis wird das Skript distnotedein- oder zweimal am Tag abgebrochen. Dies geschieht normalerweise nach dem backupdStart.

Für diejenigen, die mit der Verwendung der OS X-Shell (Befehlszeile) nicht vertraut sind, werden mit dem folgenden Skript sowohl das checkdistnotedSkript als auch der crontab-Eintrag installiert :

#!/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
}

Sie müssen das oben Genannte als install_checkdistnoted.shauf Ihrem Desktop speichern , dann ausführen Applications/Utilities/Terminalund Folgendes eingeben:

cd Desktop
sh install_checkdistnoted.sh 

Wenn es vollständig funktioniert, wird eine Bestätigung für jeden der Schritte gedruckt. Das Skript überschreibt kein vorhandenes checkdistnotedSkript oder keinen vorhandenen Crontab-Eintrag.

Michael Rourke
quelle
2
DANKESCHÖN! Tolle Lösung, die es mir ermöglicht, nicht erwähnt zu werden, aber sie herunterzufahren, wenn sie außer Kontrolle gerät. Für andere Leute wie mich, die mit der Unixy-Arbeitsweise nicht vertraut sind: 1). Ihr privater Ordner hat kein bin-Verzeichnis, erstellen Sie einen bin-Ordner unter Ihrem Benutzernamen und fügen Sie das Skript dort als Textdatei mit dem Namen "checkdisnoted" ein. 2). Um den Cron-Eintrag zu erstellen, führen Sie "crontab -e" im Terminal aus, drücken Sie die Taste "i", um in den Einfügemodus zu gelangen, und fügen Sie die gesamte Zeile mit den Sternchen ein. Drücken Sie dann "esc", um in den Befehlsmodus zurückzukehren, und geben Sie ein ": wq" um die Datei zu speichern und den Editor zu verlassen.
Mike
@ Michael Rourke: Dies ist eine großartige Lösung. Das Installationsskript enthält jedoch Syntaxfehler unter der von meinem Mac eingebauten Bash "GNU Bash, Version 3.2.57 (1) -Release (x86_64-apple-darwin15)". Das "||" Logikkürzel und "<< -" scheinen hier nicht zu funktionieren.
Kakyo
@kakyo - sehr leid, das Skript ist fehlgeschlagen, da ein Tabulator zu Leerzeichen wurde - jetzt behoben.
Michael Rourke
8

Ich gab auf und ging auf den Vorschlaghammer zu: Töte ihn automatisch, jede Minute. Seufzer.

ich stelle dies ein 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>

und dann installiert es mit launchctl load ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist.

Ryan
quelle
1
Michael Rourkes Ansatz unten ist ein Touch Cleaner, da er nur tötet, wenn er anfängt, CPU zu essen.
Mike
@mike aber Michael Rourke Ansatz befasst sich nicht mit Fällen, in denen disnotedRAM isst.
Cœur
@ Cœur - Ja. Ich habe keine Probleme mit dem Essen von RAM. War das ein Problem, das Sie gesehen haben?
Mike
1
@mike ja, disnotedhabe gestern 63 GB RAM in meiner High Sierra gegessen. Sogar Ryan gibt in seiner Frage an, dass der Prozess eine Menge Gedächtnis gekaut hat .
Cœur
@ Cœur - guter Punkt! Ich habe sie aufgewertet.
Mike
4

Ich habe verschiedene Kombinationen von Stripping-Anpassungen durchgeführt, um dieses Verhalten einzugrenzen. Ich denke, es ist Comint-Modus. Auf 10.9 mit Emacs 24.3.1 von Homebrew (oder von Emacsforosx) tritt das distnoted + Emacs-Leck (beide erhöhen langsam den Speicherverbrauch) mit einem geöffneten Shell-Modus-Puffer auf. Es wird nicht, wenn Sie nur Dateien besuchen.

Wollte es hier nur notieren, gmane scheint nicht in Betrieb zu sein und ich finde diese Diskussion immer wieder auf meiner zweimal wöchentlichen Suche nach Folgemaßnahmen zu diesem Problem.

Lang Martin
quelle
Vielen Dank! Ich könnte tatsächlich das Gleiche sehen. Ich dachte, das neutrale Rampenlicht (die akzeptierte Antwort) hätte für mich funktioniert, aber ich sehe immer noch außer Kontrolle geratene Distnoteds. Nochmals vielen Dank für die Führung, ich kann dies folgen und mehr zu debuggen.
Ryan
Ich glaube, es hat auch etwas mit meinem Emacs-Prozess zu tun. distnoted hat sich beruhigt, als ich Emacs erledigt habe. Ich habe server.el, edit-server.el und eine Python-Shell, die zu jeder Zeit für den Datensatz ausgeführt wird.
Lester Cheung
Dasselbe sehen! Emacs schuld!
Justingordon
Ich weiß nicht einmal, was der Comint-Modus ist, und manchmal habe ich das Problem mit dem Emacs. Vielleicht ist also kein bestimmtes Paket schuld.
Huyz
2

Ich denke, ich kann mich nur an zwei Gelegenheiten erinnern, bei denen Distnoted durcheinander geraten ist. Bei dieser Gelegenheit saßen 2 von ihnen an der Spitze der CPU-Liste und einer war über 400%. Es geschah kurz nachdem ich ins Büro zurückgekehrt war und ein paar externe Displays angeschlossen hatte - von denen eines mit USB betrieben wird -, vermutete ich, dass es damit zusammenhängen könnte. Ich habe nichts anderes unternommen, um das Problem zu beheben, bevor ich das USB-Display herausgezogen habe, was sofort wieder zur Vernunft geführt hat. Und dann wieder einstecken führte zu keinem Wiederholungsproblem.

Welches beweist was? Keine Ahnung!

Ich schließe sie hunderte Male an, und dies ist das erste Mal, dass mir der Gedanke kam, dass es etwas damit zu tun haben könnte. Und da es nicht jedes Mal passiert, wenn ich sie einstecke, hat es möglicherweise etwas damit zu tun, dass beide zu schnell hintereinander gesteckt werden oder so etwas Zufälliges. Jedenfalls dachte ich, ich würde teilen, falls andere Leute finden, dass es irgendetwas mit dem Anschließen von Peripheriegeräten zu tun hat (wenn es das ist, was ein externer Bildschirm ist)

petednz - Fuzion
quelle
Ich hatte eine ähnliche Situation. Wenn ich meinen USB-Grafikadapter entfernte, verbrauchte er nicht mehr viel CPU (laut "top"), und wenn ich ihn wieder einsteckte, trat das Problem nicht sofort wieder auf.
Dalbergia,
Dies stellte sich auch für mich als Problem heraus. Danke!
Eric Simonton
2

Dies scheint zu passieren, wenn eine Anwendung die von macOS bereitgestellte Benachrichtigungs-API irgendwie falsch verwendet. In meinem Fall war iTerm2 der Täter. Nach dem Beenden wurden die distnotedProzesse beendet. Andere Schuldige, die identifiziert wurden, sind Emacs und iTunes.

xApple
quelle
1
iTerm2 verursacht es auch für mich.
CTC
0

Ich konnte dieses Problem beheben, indem ich meine Antivirensoftware deaktivierte.

David P. Caldwell
quelle
0

Das passierte mir auch, distnoted wurde verrückt. Nach dem Schließen einer Reihe von Anwendungen hat nichts geholfen.

Dann bemerkte ich, dass einer dieser "Report to Apple" -Dialoge eines abgestürzten Python-Prozesses die ganze Nacht offen blieb.

Obwohl es nur Zufall sein konnte, beruhigte sich nach dem Schließen des Dialogs der distnoted Prozess.

Chris
quelle
0

Ich bin vor einigen Monaten auf ein ähnliches Problem mit Distnoted gestoßen und konnte nicht feststellen, warum die CPU-Auslastung über 100% stieg. Schließlich fügte ich killall distnotedalle 2 Minuten einen Eintrag zu meiner Crontab hinzu, der mein Problem löste.

Vor kurzem hatte ich ein Problem mit Sublime Text, bei dem durch Eingabe subl path/to/filedie Datei im Sublime Editor nicht richtig geöffnet werden konnte. Ein Neustart der App behebt das Problem, aber es begann schnell wieder zu geschehen.

Nachdem ich mir den Kopf zerbrochen hatte, stellte ich fest, dass ich alle zwei Minuten einen verdrehten Prozess beendet hatte, um herauszufinden, warum der Befehl subl auf mysteriöse Weise nicht mehr funktionierte.

Das Fazit: Die extrem hohe CPU-Auslastung könnte mit dem Erhabenen zusammenhängen. Jetzt, da sublime aktualisiert wurde, ist meine Schlussfolgerung hoffentlich richtig, die CPU-Auslastung bleibt niedrig, und mein subl-Befehl funktioniert wieder wie erwartet, da distnoted wieder ausgeführt wird, ohne dass meine crontab den Prozess alle 2 Minuten abbricht.

finiteloop
quelle
0

Ich habe auch dieses Problem seit geraumer Zeit, aber mit Unterbrechungen. Anscheinend ist distnoted Teil von iTunes und hat auch unter Windows Probleme verursacht . Als ich iTunes (das ein Lied abspielte) beendet habe, war der distontedProzess, bei dem 400% meiner CPU (ich habe 4 Kerne) verbraucht waren, kein Problem mehr.

Daher ist meine Antwort, bis ich es besser weiß, zu empfehlen, iTunes zu töten, nicht zu töten distnoted, und uns mitzuteilen, was passiert.

vy32
quelle
-1

Ich sehe auch Distnoted Go Haywire, in meinem Fall scheint es mit Fontd verwandt zu sein. Ich habe drei Distnoted Running, eine für Spotlight, eine für Distnote und eine für meinen Benutzer.

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

Immer wenn distnoted CPU (30-90%) isst, essen fontworker und fontd jeweils etwa 30-60% CPU. Sobald ich fontd, distnoted und fontworker für meinen Benutzer töte, beruhigt sich. Fontworker zu töten bringt nichts. Nach ein paar Minuten, in denen fontd neu gestartet wurde und eine Weile lief, beginnt alles von vorne.

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

Ich habe keine Ahnung, warum das passiert ...

Nils
quelle
-2

Peter Buckley hat recht, ich liege falsch. Ich hasse es, wenn das passiert.

Entferne Distnoted nicht, der nächste Boot wird überhaupt keinen Spaß machen.

falsch> Ich habe mich mehr dem Vorschlaghammer zugewandt
falsch> 
falsch> sudo mv / usr / sbin / distnoted /usr/bin/distnoted.unwanted
falsch>
falsch> Dies ist eine Arbeitsmaschine und ich habe kein Interesse daran, mit iTunes zu synchronisieren.

ConorR
quelle
Das ist verrückt. Wie auf Apples Seite über distnoted erwähnt , ist distnoted Teil von OS X, befasst sich mit verteilten Benachrichtigungen und gibt es seit mindestens 2005.
jfmercer
Was auch immer Sie tun, bewegen Sie sich NICHT distnotedwie in ConorR erwähnt (und später korrigiert, danke!), Es ist erforderlich, OSX zu booten (10.9.5 in meinem Fall).
Peter Buckley
Soweit dies keine wirkliche Antwort ist, halte ich es für wichtig, dass dies irgendwo auf der Seite vermerkt bleibt. Ich überlegte fast, ob ich mich distanziert bewegen sollte.
Zenexer