processo distaccato a distanza

Riepilogo dall'OP : questo è stato un ottimo strumento per il debug. Inizialmente mi indicava Spotlight che reindicizzava il filesystem, ma restringevo le cose a cui era consentito indicizzare, e vedevo ancora il problema. Ho finito con l'impostare un cron job per uccidere i dati a intervalli regolari. Vedi la risposta più in basso.

Puoi eseguire il debug di Distnotating creando il file /var/log/do_dnserver_log Ciò causa il server CFNotificationCenter ( distnoted ) per registrare le informazioni su tutte le notifiche nel registro di sistema.

Vorrei iniziare da lì, riavviare e guardare il registro di sistema quando la CPU aumenta. Questo dovrebbe far uscire il colpevole facilmente.

Maggiori informazioni su CFNotificationCenter debugging possono essere trovate 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 con dati distanziati si calma in pochi secondi dopo essere uscito da Emacs.

Ho registrato un bug Emacs qui: link

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

link

Ho avuto gli stessi problemi con distnoted su El Capitan per qualche tempo. La mia soluzione non è così dura come ucciderla regolarmente, piuttosto la controllo per farlo andare fuori controllo (elevato utilizzo della CPU), e poi ucciderlo. Io 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 distnoted una o due volte al giorno e in genere ciò si verifica dopo l'avvio di backupd .

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

Devi salvare quanto sopra come install_checkdistnoted.sh sul desktop, quindi eseguire Applications/Utilities/Terminal e digitare:

cd Desktop
sh install_checkdistnoted.sh 

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

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

lo metto 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>

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

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

Volevo solo prenderlo in considerazione qui, gmane sembra essere in disuso e continuo a trovare questa discussione sulla mia ricerca bisettimanale di followup a questo problema.

Penso di poter ricordare solo 2 occasioni in cui il distnoted è andato in tilt. In questa occasione c'erano 2 di loro 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 schermi esterni, uno dei quali è alimentato tramite usb, ho immaginato che potesse essere collegato. Non ho fatto nient'altro per provare a risolvere il problema prima di estrarre il display USB, cosa che ha riportato immediatamente il benessere mentale. E poi ricollegarlo non ha provocato alcun problema di ripetizione.

Quale prova cosa? Non ne ho 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 accade ogni volta che li collego, potrebbe avere qualcosa a che fare con il collegarli entrambi troppo in fretta uno dopo l'altro, o qualcosa di casuale come quello. Comunque pensavo che avrei condiviso nel caso in cui altre persone trovassero che ha qualcosa a che fare con l'inserimento di periferiche (se questo è ciò che è uno schermo esterno)

Questo sembra accadere quando un'applicazione in qualche modo fa un uso errato dell'API di notifica fornita da macOS. Nel mio caso il colpevole era iTerm2. Dopo averlo chiuso, i processi distnoted sono terminati. 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 distnoted stavano impazzendo. Dopo aver chiuso un mucchio di applicazioni, nulla ha aiutato.

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

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

Mi sono imbattuto in un problema simile con distnoted alcuni mesi fa e non sono riuscito a rintracciare il motivo per cui l'utilizzo della CPU era superiore al 100%. Infine, ho aggiunto una voce al mio crontab a killall distnoted ogni 2 minuti che ha risolto il mio problema.

Recentemente, ho riscontrato un problema con Sublime Text, in cui digitare subl path/to/file non riusciva ad aprire correttamente il file nell'editor di Sublime. Un riavvio dell'app ha risolto il problema, ma ha ripreso rapidamente a verificarsi.

Dopo aver rovinato il mio cervello a non finire, ho identificato il fatto che stavo uccidendo processi distalotati ogni 2 minuti per spiegare perché il comando subl ha misteriosamente smesso di funzionare.

La conclusione: l'utilizzo della CPU molto elevato potrebbe essere stato correlato al sublime. Ora che il 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 è in esecuzione di nuovo senza che il mio crontab uccida il processo ogni 2 minuti.

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

Quindi la mia risposta, finché non lo so, è raccomandarti di uccidere iTunes, non distnoted , e facci sapere cosa succede.

Vedo anche che le note distorcono, nel mio caso sembra correlato a fontd. Ho tre versioni distnoted, una per _spotlight, una per _distnote e una 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 distnoted mangia cpu (30-90%), fontworker e fontd mangia circa il 30-60% della CPU ciascuno. Non appena ho ucciso fontd, distnoted e fontworker per il mio utente si calma. Killing fontworker non fa nulla. Dopo un paio di minuti, quando fontd è stato 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 sta accadendo ...

Peter Buckley ha ragione, ho torto. Odio quando ciò accade.

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

wrong> I took a more sledgehammer approach
wrong> 
wrong>    sudo mv /usr/sbin/distnoted /usr/bin/distnoted.unwanted
wrong>
wrong> This is a work machine and I have no interest in sync'ing with iTunes.