Como investigar a causa da falta de resposta no Linux? [fechadas]

Question

Peço desculpas pelo problema que estou escrevendo não é muito concreto. Eu uso o KDE4 no teste Debian, e uso o gerenciador de arquivos do KDE, o Dolphin, muitas vezes, na maioria das vezes sem problemas. Recentemente, suponho que após uma atualização do sistema, o Dolphin geralmente não responde muito. Isso pode acontecer diretamente na inicialização - cerca de um minuto se passa antes que a janela apareça - e também pode acontecer depois, depois de algum tempo, que tudo está bem. O conteúdo da janela não é mais atualizado, leva-se muito tempo até que um arquivo seja aberto após ser clicado, etc. Uma reinicialização às vezes faz o problema desaparecer, mas não por muito tempo. Eu pensei que poderia ter a ver com o acesso à unidade óptica, mas o problema permanece mesmo se não houver mídia na unidade. - Eu não tenho nenhum sistema de arquivos de rede montado. Também não há outros processos que consumam tempo de CPU e / ou largura de banda de disco.

Agora, a pergunta que estou fazendo não é sobre esse problema específico com o Dolphin, mas isso:

How can I generally deal with the situation that a program becomes unresponsive? Is there a standard strategy to find out what causes such a problem, so that 1) I might find a fix or workaround for myself and/or 2) be able to submit a useful bug report?

Neste caso, porque pensei que poderia ter a ver com o Dolphin tentando acessar certos arquivos e pendurado porque há algum tipo de bloqueio, iniciei o dolphin com strace e tentei entender as mensagens. No entanto, existem muitos "erros" do tipo "EAGAIN (Recurso temporariamente indisponível)" ou "ENOENT (Nenhum arquivo ou diretório)", a maioria dos quais não parece representar um problema. A única coisa que aprendi de forma confiável é que, mesmo que o Dolphin não reaja à entrada do usuário, isso não significa que não haja muita coisa acontecendo em resposta a movimentos do mouse e cliques do mouse ...

O strace é a ferramenta certa? Se sim, o que devo procurar em sua saída? Se não, o que devo usar em vez disso?

    

Answer 1

Bem, o strace imprime uma lista de chamadas do sistema feitas pelo programa. Pode ser útil e educativo usá-lo, mas se você não for um programador, pode não ser muito prático.

htop

Se o que você quer é tornar o sistema mal-responsivo voltando ao estado de trabalho, então um dos programas mais úteis que eu encontrei é o htop. Basicamente, mostra o uso do sistema em tempo real em um terminal. Você deve ler um pouco sobre isso - está muito bem documentado e alguns artigos foram publicados sobre isso. Você usá-lo em um terminal, portanto, se sua área de trabalho congelou, mas se você ainda pode fazer login no seu computador via ssh ele funciona. Por exemplo. da sua máquina windows via pUTTY. Ele fornece uma lista de processos e mostra as informações mais importantes sobre eles. Com a F6, você classifica os processos por uso específico de recursos (por exemplo, processador, memória, swap) e, portanto, você pode ver qual programa é o recurso hog. Com F4 você pode filtrar por nome do programa - basta começar a digitar. A F5 mostra a árvore de processos e provavelmente mostrará quais arquivos estão abertos pelo seu programa. Com o F9, você pode enviar o sinal KILL que quiser para o programa. O interessante é que você pode simplesmente mover para cima e para baixo com as teclas de seta e pressionar os números para selecionar opções - você deve experimentar um pouco para apreciar isso.

Minha regra é - se o sistema não está tão pendurado que pressionar NumLock não piscará a luz NumLock, então há chances de que algumas investigações simples e - SIGHUP ou SIGKILL do htop o trarão de volta à estabilidade. Se a situação se repetir, você poderá preencher o relatório de erros.