processo distinto in fuga

A volte vedo un distnotedprocesso improvvisamente girare e masticare CPU al 100% (su un core) e una tonnellata di memoria, spesso in prossimità di 1,5 G circa. Questo succede alcune volte al giorno, a partire da circa un mese fa.

La riga di comando è /usr/sbin/distnoted agented è avviata da launchdnessuno dei quali aiuta molto. Di solito è in esecuzione da qualche parte tra le 4h e le 24h prima che giri e pioli la CPU.

Le ricerche sul web dicono che distnotedgestisce la consegna delle notifiche e molte altre persone segnalano lo stesso problema, ma non ho ancora trovato una soluzione. Alcuni ritengono che la chiusura di un'applicazione colpevole (ad esempio Skype) la interrompa, ma non ho ancora trovato un colpevole sulla mia macchina. Di solito utilizzo solo alcune app: Emacs (24.2 da Homebrew), Firefox, Adium e Dash.

Sono su Mavericks su un Retina MBP da 13 "alla fine del 2012. Grazie in anticipo!

Aggiornare:

Ho attivato la distnotedregistrazione nel registro di sistema toccando /var/log/do_dnserver_log, ma non aiuta molto. Vedo righe come queste (io sono 501, 89 non l'ho ancora trovato):

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.

Ho anche eseguito sudo dtruss -p PIDun distnotedprocesso di spun-up e emette linee come questa:

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

Riepilogo dall'OP : questo è stato un ottimo strumento per il debug. Inizialmente mi ha indicato Spotlight che reindicizza il filesystem, ma ho ristretto le cose che è consentito indicizzare e ho ancora riscontrato il problema. Ho finito per impostare un lavoro cron per uccidere regolarmente i distnotati. Vedi la risposta più in basso.

È possibile eseguire il debug delle informazioni distinte creando il file /var/log/do_dnserver_log Questo fa sì che il CFNotificationCenterserver ( distnoted) registri le informazioni su tutte le notifiche nel registro di sistema.

Vorrei iniziare lì, riavviare e guardare il registro di sistema quando la CPU si alza. Questo dovrebbe facilmente eliminare il colpevole.

Maggiori informazioni sul CFNotificationCenterdebug sono disponibili nei documenti ufficiali dello sviluppatore qui: Nota tecnica TN2124> CFNotificationCenter

Ho visto anche questo. Emacs 24.3.1, Mavericks 10.9.

Ho scoperto che il processo distnoted si calma dopo pochi secondi dopo aver lasciato Emacs.

Ho presentato un bug di Emacs qui: http://permalink.gmane.org/gmane.emacs.bugs/80836

So di essere in ritardo alla festa, ma questa è una perdita di memoria specifica degli emacs di cacao su Mavericks che è stata riparata nel bagagliaio. Per ora c'è una patch che puoi usare per compilare emacs 24.3 con solo la correzione.

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

Ho avuto gli stessi problemi con distnotedEl Capitan da qualche tempo. La mia soluzione non è così dura come ucciderla regolarmente, ma cerco che sia fuori controllo (elevato utilizzo della CPU), quindi la uccido. Uso questo 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) 
    }
    '

Lo script viene eseguito da cron ogni minuto con questa riga in crontab:

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

In pratica, lo script uccide distnoteduna o due volte al giorno e in genere ciò si verifica dopo l' backupdavvio.

Per coloro che non si sentono a proprio agio con l'uso della shell OS X (riga di comando), il seguente script installerà sia lo checkdistnotedscript che la voce 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
}

È necessario salvare quanto sopra come install_checkdistnoted.shsul desktop, quindi eseguire Applications/Utilities/Terminale digitare:

cd Desktop
sh install_checkdistnoted.sh 

Se funziona completamente stamperà la conferma di ciascuno dei passaggi. Lo script non sovrascriverà uno checkdistnotedscript esistente o una voce crontab.

ho rinunciato e ho adottato l'approccio della mazza: uccidilo automaticamente, ogni minuto. sospiro.

ho inserito questo ~/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>

e poi installato con launchctl load ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist.

Ho fatto diverse combinazioni di personalizzazioni di stripping per restringere questo comportamento; Penso che sia la modalità Comint. Il 10.9 con emacs 24.3.1 da homebrew (o da emacsforosx) la perdita distnotata + emacs (entrambi aumentano lentamente nel consumo di memoria) avverrà con un buffer in modalità shell aperto. Non lo farà se si visitano solo i file.

Volevo solo annotarlo qui, gmane sembra essere inattivo e continuo a trovare questa discussione sulla mia ricerca bisettimanale di follow-up a questo problema.

Penso di ricordare solo 2 occasioni in cui Distnoted è andato in tilt. In questa occasione c'erano 2 di loro seduti in cima alla lista della CPU e uno era oltre il 400%. È successo poco dopo essere tornato in ufficio e aver collegato un paio di display esterni - uno dei quali è alimentato via USB - ho pensato che potesse essere correlato. Non ho fatto altro per provare a risolvere il problema prima di estrarre il display USB che ha riportato immediatamente la sanità mentale. E quindi ricollegarlo non ha comportato problemi di ripetizione.

Quale prova cosa? Nessuna idea!

Li collego centinaia di volte e questa è la prima volta che mi viene in mente che potrebbe essere correlato. E dal momento che non succede ogni volta che lo collego, allora potrebbe avere qualcosa a che fare con collegarli entrambi troppo rapidamente uno dopo l'altro o qualcosa di casuale come quello. Comunque ho pensato di condividere nel caso in cui altre persone trovassero che ha qualcosa a che fare con il collegamento delle periferiche (se è quello che è uno schermo esterno)

Questo sembra accadere quando un'applicazione fa in qualche modo un uso errato dell'API di notifica fornita da macOS. Nel mio caso il colpevole era iTerm2. Dopo averlo abbandonato, i distnotedprocessi sono usciti. Altri colpevoli che sono stati identificati sono Emacs e iTunes.

Per quello che vale, sono stato in grado di risolvere questo problema disabilitando il mio software antivirus.

Questo è successo anche a me, i distnotati stavano impazzendo. Dopo aver chiuso un sacco di applicazioni, nulla ha aiutato.

Poi ho notato che una di quelle finestre di dialogo "Segnala ad Apple" di un processo Python bloccato era rimasta aperta tutta la notte.

Anche se potrebbe essere solo una coincidenza, dopo aver chiuso la finestra di dialogo, il processo distinto si è calmato.

Mi sono imbattuto in un problema simile con distnotato alcuni mesi fa e non sono riuscito a rintracciare il motivo per cui l'utilizzo della CPU era al di sopra del 100%. Alla fine, ho aggiunto una voce al mio crontab killall distnotedogni 2 minuti che ha risolto il mio problema.

Di recente, ho riscontrato un problema con Sublime Text in cui la digitazione subl path/to/filenon riusciva ad aprire correttamente il file nell'editor Sublime. Un riavvio dell'app ha risolto il problema, ma ha ricominciato rapidamente a verificarsi.

Dopo aver distrutto il mio cervello fino in fondo, ho identificato il fatto che stavo uccidendo il processo distnotato ogni 2 minuti sul perché il comando subl avesse misteriosamente smesso di funzionare.

La conclusione: l'utilizzo super elevato della CPU potrebbe essere stato collegato al sublime. Ora che sublime è stato aggiornato, si spera che la mia conclusione sia corretta, l'utilizzo della CPU rimane basso e il mio comando subl torna a funzionare come previsto ora che distnoted è di nuovo in esecuzione senza che il mio crontab uccida il processo ogni 2 minuti.

Anch'io ho avuto questo problema, già da un po 'di tempo, ma a intermittenza. Apparentemente distinto è parte di iTunes e ha causato problemi anche su Windows . Quando ho ucciso iTunes (che stava riproducendo una canzone), il distontedprocesso che utilizzava il 400% della mia CPU (ho 4 core) ha smesso di essere un problema.

Quindi la mia risposta, fino a quando non lo saprò meglio, è di raccomandare di uccidere iTunes distnoted, e di farci sapere cosa succede.

Vedo anche distnoted go haywire, nel mio caso sembra legato a fontd. Ho tre distnotati in esecuzione, uno per _spotlight, uno per _distnote e uno per il mio utente.

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

Ogni volta che la distnota mangia cpu (30-90%), fontworker e fontd mangiano circa il 30-60% cpu ciascuno. Non appena uccido fontd, distnoted e fontworker per il mio utente si calma. Uccidere fontworker non fa nulla. Dopo un paio di minuti, quando fontd si è riavviato ed è in esecuzione da un po ', tutto ricomincia.

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

Non ho idea del perché questo stia accadendo ...

Peter Buckley ha ragione, mi sbaglio. Lo odio quando succede.

Non rimuovere distnoted, il prossimo avvio non sarà affatto divertente.

sbagliato> Ho adottato un approccio più mazza
sbagliato> 
sbagliato> sudo mv / usr / sbin / distnoted /usr/bin/distnoted.unwanted
sbagliato>
sbagliato> Questa è una macchina da lavoro e non ho interesse a sincronizzarmi con iTunes.