processo descontrolado em fuga

Às vezes, vejo um distnotedprocesso girar de repente e consumir 100% da CPU (em um núcleo) e uma tonelada de memória, geralmente na faixa de 1,5 G ou mais. Isso acontece algumas vezes por dia, a partir de um mês ou mais atrás.

A linha de comando é /usr/sbin/distnoted agent, e é iniciada por launchd, nenhuma das quais ajuda muito. Geralmente, ele funciona entre 4h e 24h antes de girar e ligar a CPU.

Pesquisas na web dizem que distnotedgerencia a entrega de notificações e muitas outras pessoas relatam o mesmo problema, mas ainda não encontrei uma correção. Algumas pessoas acham que o fechamento de um aplicativo culpado (por exemplo, o Skype) o interrompe, mas ainda não encontrei um culpado na minha máquina. Normalmente, estou executando apenas alguns aplicativos: Emacs (24.2 da Homebrew), Firefox, Adium e Dash.

Estou no Mavericks no final de 2012 13 "Retina MBP. Agradecemos antecipadamente!

Atualizar:

Ativei o distnotedlogin no log do sistema tocando em /var/log/do_dnserver_log, mas isso não ajuda muito. Vejo linhas como estas (uid 501 sou eu, 89 ainda não encontrei):

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.

Também executei sudo dtruss -p PIDum distnotedprocesso acelerado e vomita linhas como esta:

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

Resumo do OP : Essa foi uma ótima ferramenta para depuração. Originalmente, ele me indicou o Spotlight reindexando o sistema de arquivos, mas reduzi o que é permitido indexar e ainda vi o problema. Eu acabei configurando um trabalho cron para matar distnoted regularmente. Veja a resposta mais abaixo.

Você pode depurar distintamente criando o arquivo /var/log/do_dnserver_log Isso faz com que o CFNotificationCenterservidor ( distnoted) grave informações sobre todas as notificações no log do sistema.

Gostaria de começar por aí, reiniciar e olhar o log do sistema quando a CPU disparar. Isso deve sair o culpado facilmente.

Mais informações sobre CFNotificationCenterdepuração podem ser encontradas nos documentos oficiais do desenvolvedor aqui: Nota técnica TN2124> CFNotificationCenter

Eu já vi isso também. Emacs 24.3.1, Mavericks 10.9.

Descobri que o processo distinto se acalma em segundos depois que eu saí do Emacs.

Arquivei um bug do Emacs aqui: http://permalink.gmane.org/gmane.emacs.bugs/80836

Sei que estou atrasado para a festa, mas esse é um vazamento de memória específico do Cocoa emacs no Mavericks, que está consertado no porta-malas. Por enquanto, existe um patch que você pode usar para criar o emacs 24.3 apenas com a correção.

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

Eu tenho tido os mesmos problemas distnotedno El Capitan há algum tempo. Minha solução não é tão dura quanto matá-la regularmente, mas verifico se ela está sem controle (alto uso da CPU) e depois a mato. Eu uso este 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) 
    }
    '

O script é executado a partir do cron a cada minuto com esta linha no crontab:

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

Na prática, o script mata distnoteduma ou duas vezes por dia, e normalmente isso ocorre após o backupdinício.

Para aqueles que não estão familiarizados com o uso do shell do OS X (linha de comando), o script a seguir instalará o checkdistnotedscript e a entrada 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
}

Você precisa salvar os itens acima como install_checkdistnoted.shna área de trabalho, executar Applications/Utilities/Terminale digitar:

cd Desktop
sh install_checkdistnoted.sh 

Se funcionar totalmente, imprimirá a confirmação de cada uma das etapas. O script não substituirá um checkdistnotedscript existente ou uma entrada crontab.

desisti e segui a abordagem da marreta: mate-a automaticamente a cada minuto. suspiro.

eu coloquei isso em ~/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 depois instalei com launchctl load ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist.

Venho fazendo diferentes combinações de personalizações de remoção para diminuir esse comportamento; Eu acho que é modo comint. No 10.9 com o emacs 24.3.1 do homebrew (ou do emacsforosx), o vazamento + emacs distnoted (ambos aumentam lentamente no consumo de memória) ocorrerá com um buffer de modo shell aberto. Não será, se você apenas visitar os arquivos.

Só queria anotar aqui, o gmane parece estar fora do ar e eu continuo encontrando essa discussão na minha pesquisa duas vezes por semana para acompanhar esse problema.

Eu acho que só consigo me lembrar de duas ocasiões em que os destroçados ficaram loucos. Nesta ocasião, havia dois deles no topo da lista de CPUs e um estava acima de 400%. Isso aconteceu logo após o retorno ao escritório e a conexão de dois monitores externos - um dos quais é alimentado por USB -, imaginei que isso pudesse estar relacionado. Não fiz mais nada para tentar resolver o problema antes de puxar a tela USB, o que trouxe de volta a sanidade instantaneamente. E, em seguida, conectá-lo novamente não resultou em nenhum problema de repetição.

O que prova o que? Nenhuma idéia!

Eu os conecto centenas de vezes e é a primeira vez que me ocorre que isso pode estar relacionado. E como isso não acontece toda vez que eu o conecto, pode ter algo a ver com conectar os dois muito rapidamente um após o outro, ou algo aleatório assim. De qualquer maneira, pensei em compartilhar caso outras pessoas achem que isso tem algo a ver com a conexão de periféricos (se é isso que é uma tela externa)

Isso parece acontecer quando um aplicativo de alguma forma faz um uso errado da API de notificação fornecida pelo macOS. No meu caso, o culpado foi o iTerm2. Depois de sair, os distnotedprocessos foram encerrados. Outros culpados que foram identificados são o Emacs e o iTunes.

Pelo que vale, consegui corrigir esse problema desativando meu software antivírus.

Isso aconteceu comigo também, desnorteado estava ficando louco. Depois de fechar um monte de aplicativos, nada ajudou.

Percebi então que uma daquelas caixas de diálogo 'Relatar para a Apple' de um processo em Python travado havia sido deixada aberta a noite toda.

Embora pudesse ser apenas coincidência, depois de fechar a caixa de diálogo, o processo distinto se acalmou.

Eu encontrei um problema semelhante com o distnoted há alguns meses e não conseguia rastrear por que o uso da CPU estava subindo acima de 100%. Por fim, adicionei uma entrada no meu crontab a killall distnotedcada 2 minutos que resolveu meu problema.

Recentemente, tenho tido um problema com o Sublime Text em que a digitação subl path/to/filefalhou ao abrir o arquivo corretamente no Sublime Editor. A reinicialização do aplicativo corrigiu o problema, mas rapidamente começou a acontecer novamente.

Depois de estancar meu cérebro sem fim, identifiquei o fato de que eu estava matando processos distintos a cada 2 minutos, por que o comando subl havia misteriosamente parado de funcionar.

A conclusão: o uso muito alto da CPU pode ter sido relacionado ao sublime. Agora que o sublime foi atualizado, espero que minha conclusão esteja correta, o uso da CPU permaneça baixo e meu comando subl volte a funcionar como esperado, agora que o distnoted está sendo executado novamente sem que meu crontab interrompa o processo a cada 2 minutos.

Eu também já tive esse problema há algum tempo, mas de forma intermitente. Aparentemente distorcido faz parte do iTunes e também causou problemas no Windows . Quando matei o iTunes (que estava tocando uma música), o distontedprocesso que estava usando 400% da minha CPU (eu tenho 4 núcleos) deixou de ser um problema.

Então, minha resposta, até que eu saiba melhor, é recomendar que você mate o iTunes e não distnoted, e deixe-nos saber o que acontece.

Eu também vejo distorcida, mas no meu caso parece relacionada ao fontd. Eu tenho três em execução distinta, uma para _spotlight, uma para _distnote e uma para o meu usuário.

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

Sempre que o distnoted consome cpu (30-90%), o fontworker e o fontd consomem cerca de 30-60% do cpu cada. Assim que eu mato fontd, distnoted e fontworker para meu usuário se acalma. Matar o fontworker não faz nada. Após alguns minutos, quando o fontd foi reiniciado e está em execução há algum tempo, tudo começa novamente.

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

Eu não tenho idéia do por que isso está acontecendo ...

Peter Buckley está certo, eu estou errado. Eu odeio quando isso acontece.

Não remova as notas distintas, a próxima inicialização não será divertida.

errado> eu tomei uma abordagem mais marreta
errado> 
incorreto> sudo mv / usr / sbin / distnoted /usr/bin/distnoted.unwanted
errado>
errado> Esta é uma máquina de trabalho e não tenho interesse em sincronizar com o iTunes.