processo descontrolado em fuga


116

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

Apenas pescando aqui, mas por qualquer mudança vocês estão correndo o fluxo ? Para mim, eles parecem estar relacionados. Se eu parar o fluxo quando o emacs ficar furioso, o emacs trava ou volta ao normal. Não tenho certeza se isso foi um acaso (apenas aconteceu duas vezes), mas se todo mundo está executando, pode haver algo a fazer.

Eu não estou executando o fluxo, mas talvez outros estejam.
ryan

o aquaemacs faz com que esse processo se repita em mim.
maratona de

Eu tive um problema muito semelhante (possivelmente o mesmo) e meu problema foi resolvido com a atualização do sistema operacional 10.9.4.
precisa

Notou isso hoje. O culpado foi o aplicativo Google Drive para OS X (10.9) (1.17.7290.4094). Primeira vez que vi isso.
Jordanpg # 10/14

Respostas:


24

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


obrigado! boa ligação, eu já fiz isso. não estou vendo nenhuma entrada distinta /var/log/system.log, mas ela também não foi ativada desde que iniciei o log. dedos cruzados.
ryan

Estou vendo linhas de log distintas agora, mas elas não são muito úteis. suspiro. exemplo: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

Tente anexar o script do DTrace a esse processo e veja o que ele realmente faz, comece com sudo dtruss -p PIDe veja quais syscalls o processo realmente tenta fazer e se houver algum com falha (o status não é 0).
Temikus

Além disso, qual é o UID 89 no seu sistema? O UID nas notificações muda? O pid 2644 corresponde a um processo distinto ou outro?
Temikus

obrigado pelas idéias! estou familiarizado strace, mas não sabia dtruss. Definitivamente vou tentar isso da próxima vez. os pids são apenas o processo distinto correspondente e os únicos uids são eu e _appserveradmum usuário interno do sistema que eu não conheço muito.
ryan

33

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


2
Também visto no Emacs v23.4.1.
WilliamKF

1
O mesmo aqui. Nunca imaginei que fosse causado pelo Emacs! Obrigado
Lionel Henry

1
Para mim, eu estou tendo o problema inverso - o Emacs começa a usar toda a CPU, e matar os problemas do meu usuário elimina o problema temporariamente. Nesse caso, observando o processo Emacs, vejo muitos threads - originários que não são do Emacs - todos aguardando na fila / mutex com.apple.root.default-overcommit-priority / runex (execute lldb, "processo anexado - pid <pid> "e, em seguida,"
encadear

e esta é uma leitura interessante sobre o que realmente são todos esses tópicos: newosxbook.com/articles/GCD.html (meu assassinato distorcido pode ser uma 'pena mágica', e não a coisa que o traz de volta ao normal)
jrg

Também visto com o Emacs v24.5 no OS X 10.11.3
Michael

23

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



1
Atualizei para uma compilação noturna do Emacs para Mac OS X (em março) e ainda tenho o problema. Parece que acontece se eu criar uma sessão interativa para R ou Clojure (linguagens de programação). O processo diferenciado subirá lentamente para GB de RAM e o liberará assim que eu sair do Emacs.
mattrepl

O mesmo problema que o @mattrepl mencionou.
Amelio Vazquez-Reina

1
O Homebrew parece ter integrado esse patch. Portanto, também brew reinstall emacs --cocoa --with-gnutlspode resolver o problema. Também deve ser corrigido em 24.4, mas ainda não está estável.
mblakele

Apenas experimentei esse problema com o Emacs 24.5 (a correção deveria estar em 24.4) .. no meu caso, o Emacs estava mostrando a bola giratória e distnoted estava usando quase 400% da CPU (por top) e matando -9 emacs não estava funcionando, mas depois de matar -HUP desmarcado emacs respondeu à matança.
Michael

17

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.


2
OBRIGADO! Solução fantástica que me permite manter-me desinteressada, mas a desliga quando fica fora de controle. Para outras pessoas como eu, que podem não estar familiarizadas com a maneira Unixy de fazer as coisas: 1). sua pasta pessoal não terá um diretório bin, crie uma pasta bin com seu nome de usuário e insira o script como um arquivo de texto chamado "checkdisnoted". 2) Para criar a entrada cron, execute "crontab -e" no terminal, pressione a tecla "i" para entrar no modo de inserção e cole toda a linha com asteriscos, depois pressione "esc" para voltar ao modo de comando e digite ": wq" para salvar o arquivo e sair do editor.
Mike

@ Michael Rourke: Esta é uma ótima solução. No entanto, o script de instalação contém erros de sintaxe no bash do meu Mac "GNU bash, versão 3.2.57 (1) -release (x86_64-apple-darwin15)". O "||" atalho lógico e "<< -" não parecem funcionar aqui.
Kakyo 21/08/16

@kakyo - desculpe, o script falhou porque uma guia se tornou espaços - corrigida agora.
Michael Rourke

8

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.


1
A abordagem de Michael Rourke a seguir é um limpador de toque, pois só mata desobedecido quando começa a comer CPU.
Mike

@ Mike, mas a abordagem de Michael Rourke não lida com casos em que disnotedestá comendo RAM.
Cœur

@ Cœur - Sim. Eu não tive um problema com a ingestão de RAM desatualizada. Esse foi um problema que você viu?
mike

1
@ Mike sim, disnotedestava comendo 63 GB de RAM na minha High Sierra ontem. Até Ryan, em sua pergunta, afirma que o processo estava consumindo uma tonelada de memória .
Cœur

@ Cœur - bom ponto! Eu os votei novamente.
mike

4

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.


obrigado! Eu posso estar vendo a mesma coisa. eu pensei que os holofotes de castração (a resposta aceita) haviam funcionado para mim, mas ainda estou vendo descontrolados. obrigado novamente pela liderança, posso seguir isso e depurar mais também.
perfil

Eu acredito que é algo para lidar com o meu processo Emacs também. Distnoted se acalmou logo depois que eu matei o Emacs. Eu tenho server.el, edit-server.el e um shell python em execução o tempo todo para o registro.
Lester Cheung

Vendo a mesma coisa! Emacs para culpar!
justingordon

Eu nem sei o que é o modo comint e às vezes tenho o problema distinto do emacs. Portanto, talvez nenhum pacote específico seja o culpado.
huyz

2

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)


Eu tive uma situação semelhante. Quando desconectei meu adaptador de vídeo USB, sem as anotações, parei de consumir CPU em excesso (de acordo com "top") e, quando o conectei novamente, o problema não reapareceu imediatamente.
Dalbergia 16/09

Isso acabou sendo o problema para mim também. Obrigado!
22618 Eric

2

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.


1
O iTerm2 também causa isso para mim.
ctc


0

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.


0

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.


0

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.


-1

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


-2

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.


Isso é loucura. Como é observado na página da Apple sobre distnoted , distnoted faz parte do OS X, lida com notificações distribuídas, e tem sido em torno desde pelo menos 2005.
jfmercer

Faça o que fizer, NÃO se mova distnotedcomo o ConorR mencionou (e depois corrigiu, obrigado!); É necessário inicializar o OSX (10.9.5 no meu caso).
Peter Buckley

Por mais que isso não seja realmente uma resposta, acho importante que isso permaneça anotado em algum lugar da página. Eu quase considerei tentar me mover desnorteado.
Zenexer 16/05/19
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.