bash process usa 90% da CPU, volta ao reinício do computador

Question

Eu substituí o disco rígido antigo do MacBook unibody do final de 2008 (8 GB de RAM, executando o OS X 10.7.4) por um SSD Vertex 3 da OCZ. Depois disso, instalei o Lion e restaurei os dados de um backup do Time Machine.

Tudo está bem, exceto por um processo chamado "bash" que usa permanentemente cerca de 90% da CPU.

Se eu mato-lo via Activity Monitor, tudo volta ao normal, mas infelizmente o processo volta toda vez que eu reinicio o computador.

Eu tentei zapar a PRAM, reinstalar o 10.7.4 do pacote combo e até mesmo esperar por mais de 2 horas, mas o problema ainda está aqui.

    

Answer 1

bash é o shell padrão no OS X - o que significa que é o programa padrão para fazer interface com os fundamentos do Darwin (tecnicamente, /bin/sh é o shell padrão, mas foi uma cópia de /bin/bash desde o OS X 10.3). É o processo que é iniciado quando você abre uma janela Terminal.app - um shell interativo.

O

bash também pode ser iniciado sem uma janela de terminal - um shell não interativo -, por exemplo, para executar scripts de shell , frequentemente denotado pelo sufixo de arquivo .sh . Esse é o caso aqui - bash está executando o script /usr/bin/stkLaunchAgent.sh , e algo neste script está mantendo seu sistema ocupado.

Agora, /usr/bin/stkLaunchAgent.sh não faz parte de uma instalação do OS X - é algum tipo de adição de terceiros e, como tal, não está presente no meu sistema, o que significa que só posso adivinhar, mas diria:

• do seu nome “LaunchAgent” e o fato de ele começar com seu sistema, que é acionado por um LaunchAgent - um pequeno arquivo de definição usado pelo OS X ' launchd , o mecanismo do sistema para iniciar scripts e programas não interativos em programação, inicialização ou outros eventos. Essa parte eu qualificaria como um palpite.
• do fato de seus problemas começarem com a instalação do seu Vertex SSD, e o fato de que a diferença crucial entre SSDs e HDs é a primeira: não use a desfragmentação e intervenções similares de baixo nível em sua estrutura, que o script lançado pelo agente em questão pode estar tentando fazer alguma operação na unidade que o Vertex SSD não aceita - o que mantém o script em execução e bash ocupado. Agora, essa parte é apenas uma suposição selvagem, mas…

Como descobrir o que o script faz:

Abra uma janela do Terminal e execute open -e /usr/bin/stkLaunchAgent.sh para dar uma espiada no shell script (esse comando irá abri-lo no TextEdit - termine-o no Activity Monitor primeiro) - isso deve lhe dar os meios para ver exatamente o que está sendo executado.

Como se livrar disso:

Você terá que se livrar do LaunchAgent, se realmente for um. launchd Os arquivos do LaunchAgent estão no formato plist e encontrados em

• ~/Library/LaunchAgents - somente para a conta de usuário atual
• /Library/LaunchAgents - para todas as contas de usuário
• /System/Library/LaunchAgents - agentes no nível do sistema (não devem ser encontrados aqui!)

Eles geralmente são nomeados em notação de domínio reverso ( tld.domain.process.plist ). Dependendo se a conta de usuário do seu runaway bash é sua ou não, você deve procurar em um dos dois primeiros locais acima por uma plistição provável (se você tiver o Xcode instalado, poderá QuickLook facilmente). O procedimento correto para pará-lo é removê-lo da lista de processos do launchd por meio de

launchctl unload tld.domain.process

que descarregará e interromperá o processo (observe que você omite o sufixo plist ).

Existe também uma GUI para lidar com arquivos launchd , Peter Borg's Lingon (certifique-se de obter "Lingon", não "Lingon 3", que é uma versão simplificada segura para uso baunilha), que pode ser mais conveniente do que procurar manualmente pelo arquivo localizações.

Histórico:

• bash no OS X de David Miller (de 2004, mas ainda é uma boa introdução)
• artigo do launchd na Wikipedia

Answer 2

Eu olhei dentro do arquivo e aprendi sua parte do aplicativo Save to Kindle que instalei há algumas semanas. O aplicativo tem um desinstalador em / Applications, então eu fiz isso em vez de excluir o .sh diretamente. Trabalhou.

    

Answer 3

Eu tive o mesmo problema após migrar meu sistema para um SSD Crucial M4. Eu "resolvi" isso excluindo /usr/bin/stkLaunchAgent.sh, pois não havia demônios de lançamento diretamente relacionados ao arquivo.

Eu ainda gostaria de saber de onde veio esse arquivo e por que isso ocorreu ...

    

Answer 4

Eu resolvi o mesmo problema no meu computador usando chown para possuir o pipe de comunicação presente em /var/spool/stkPrinter/username/stkPipe .

O problema ocorre porque a propriedade (talvez as permissões também?) do pipe muda após a migração para uma nova unidade. O script /usr/bin/stkLaunchAgent.sh tem alguma permissão básica / verificação de propriedade incorporada, mas obviamente não é suficiente. Ele acaba no loop while true tentando acessar o pipe e os logs são completamente ultrapassados por mensagens de erro.

Eu nem teria notado isso se não percebesse que meus backups do Time Machine estavam sendo inexplicavelmente grandes, foi quando olhei para os registros do sistema e vi milhões de linhas reclamando da mesma coisa. O arquivo de log /var/spool/stkPrinter/username/stkPrint.log foi 15GB grande!