Acidentes aleatórios no XFCE - como diagnosticar o que está acontecendo?

Question

Estou no Parabola (um fork do Arch) e estou executando o ambiente de desktop XFCE. No entanto, eu periodicamente recebo essas falhas estranhas, onde toda a minha área de trabalho congela. Eu não tenho capacidade de mover meu cursor (na verdade, eu nem consigo ver meu cursor), minha máquina não responde a qualquer entrada de teclado (eu posso) nem mude para outro tty), e basicamente apenas o botão liga / desliga funciona. No entanto, ao mesmo tempo, se eu (por exemplo) tiver música tocando em segundo plano, ela continuará tocando sem problemas.

Não sei bem como diagnosticar a origem do meu problema. Onde posso procurar e o que estaria procurando para detectar o que causa tal comportamento?

    

Answer 1

Se a sua música continuar tocando por mais de alguns segundos, isso significa que o sistema está rodando bem, exceto que o servidor X está tão congelado que não responde a nenhuma entrada do console. Alternar entre ttys requer a cooperação do servidor X, tanto para lidar com a combinação de teclas quanto para redefinir a placa gráfica.

Se você tiver outra maneira de fazer login na máquina, poderá executar comandos e tentar depurar o problema ou, pelo menos, executar um desligamento limpo. Para a maioria das pessoas, uma maneira de acessar a máquina seria o SSH de outro computador (que pode ser um smartphone - existem emuladores de terminal e clientes SSH para os principais sistemas operacionais de smartphone).

A partir de uma linha de comando, você pode tentar executar chvt 1 como root para alternar para um console de texto diferente. Isso pode ou não funcionar, dependendo do que o servidor X está fazendo. Se o servidor X não estiver respondendo, o switch pode falhar, ou você pode acabar digitando cego porque o modo gráfico do console de texto não foi configurado corretamente.

Outra coisa que pode ser útil é o SysRq mágico : pressione e segure Alt , pressione SysRq (você pode soltá-lo), pressione uma letra mnemônica e solte todas as teclas. Isso é tratado diretamente pelo kernel, então continuará trabalhando desde que o kernel não esteja completamente bloqueado. Se você não tem acesso SSH, tente pressionar Alt + SysRq + R para mudar o teclado para fora do modo raw, então pressione Ctrl + Alt + F1 para mudar para uma consola de texto. Quando o teclado não está mais no modo raw, a ligação de chave é tratada diretamente pelo kernel, portanto, isso tem uma chance de funcionar. Como executando chvt , o comutador VT real pode ser prejudicado pelo servidor X.

Se você conseguir obter uma linha de comando, aqui estão algumas coisas que você pode considerar como um primeiro nível de investigação:

• Execute htop ou top e veja quais processos estão mantendo a CPU ocupada.
• Verifique se há mensagens em /var/log/Xorg.0.log , /var/log/kern.log (ou onde quer que sua distribuição mantenha registros do kernel) ou ~/.xsession-errors (ou onde quer que seus gerentes de sessão direcionem stdout e stderr).

Se algum processo X estiver demorando 100% do tempo da CPU ou compartilhando com o servidor X, tente matá-lo. O Compiz é um infrator frequente.

Você pode usar Alt + SysRq + K então Alt + SysRq + R para matar o servidor X e todos os processos na sessão X. Isso também deixará a placa gráfica em um estado ruim. Você pode então rodar um novo servidor X, há uma boa chance de que ele possa reinicializar a placa gráfica.

Problemas comuns que causam travamentos são:

• Um driver de gráficos 3D com bugs. Drivers 3D são muito mais problemáticos do que 2D (isso é compreensível, uma vez que são mais novos, mais complexos e ainda mais mal suportados pelos fabricantes de hardware). Tente confiar menos em coisas 3D. Em particular, evite compiz.
• Um driver gráfico com bugs. Se você estiver usando o driver gratuito para sua GPU, tente o proprietário, ou vice-versa. Experimente uma versão mais recente ou mais antiga.
• RAM ruim. Execute um teste de memória .