kill -9 trava, incapaz de matar processo (processo de prova de assassinato) [duplicado]

Question

Acho que é um pouco tarde para perguntar isso, mas para referência futura;

Eu fui chamado para ver um servidor hoje depois que um cliente relatava que a conexão com o ssh era lenta e a execução de comandos também era lenta (com alguns não funcionando)

Após o login, eu consegui digitar rapidamente, então não achei que fosse um problema de rede como atraso ou saturação de largura de banda (acho que isso tende a ser diretamente relacionado às suas experiências ssh). Primeiro tentei executar top , depois de um minuto de nada acontecer, cancelei essa operação com CTRL + C. O prompt estava aguardando a inicialização de top .

free -m também estava pendurado no prompt por um minuto ou mais antes de eu cancelá-lo.

df -h foi executado e me mostrou que havia 60% de espaço livre em disco (fiquei me perguntando se algum aplicativo tinha sido banido e preenchido os discos com logs).

dmesg também não executaria.

Eu executei tail -n 50 /var/log/message e, infelizmente, não tenho mais a saída, mas parece que houve um problema sério. Muitos locais de memória impressos em HEX e presumivelmente seu conteúdo (divagações incompreensíveis) à direita. Foi muito parecido com a saída em este log que encontrei no Google, tentando encontrar um exemplo semelhante, exceto que na coluna da direita a maioria das linhas contém "ext4", talvez tenha ocorrido um erro no sistema de arquivos?

Correndo tail -n 50 /var/log/syslog Vi no meio de toda a loucura de memória que foi repetida aqui algumas linhas que diziam que funcionavam como Info procname:pid blocked for more than 120 seconds .

Eu executei ps aux e examinei a saída até encontrar um processo com 299% de uso da CPU;

ps aux | grep procname

procuser    8279  299  0.0 479064 41916 pts/6    Sl+  08:05 548:31 /path/to/procname procbox 6390 6394 6395 0

Portanto, este processo tem sido absurdo, mas não consigo executar nenhum comando (com ou sem sudo) relacionado à memória. Por exemplo, free -m ou top . Eu poderia cat /proc/meminfo e ver que havia cerca de 5 GB de 40 GB de RAM livre.

Eu tentei kill PID , mas depois de alguns minutos de suspensão eu desisti. Eu tentei kill -9 PID mas novamente, a mesma coisa. Eu só posso supor que este processo foi tão ocupado que não poderia responder a matar mensagens do kernel? Eu tentei renice 19 PID e kill -9 PID , mas isso não funcionou também, renice seria executado, apenas desligue.

No final, foi necessária uma reinicialização rígida que não era ideal. Os arquivos estão corrompidos, etc, devido aos aplicativos especializados no servidor. Quais outras opções eu tenho?

Não há como simplesmente interromper um processo? Em vez de enviar um SIGTERM, simplesmente cessar o processamento de código ou algo semelhante?

    

Answer 1

I executed tail -n 50 /var/log/message and sadly I no longer have the output but it looked like there had been a serious problem. Lots of memory locations printed in HEX and presumably their contents (incomprehensibly ramblings) on the right.

Poderia ter sido praticamente qualquer coisa, e o conteúdo desses depósitos de kernel seria importante para saber o que era.

Por exemplo, você poderia ter um problema de hardware, como um disco que não estava mais respondendo a solicitações. Tentar executar programas que já foram armazenados em cache na RAM pode funcionar bem, enquanto a execução de programas que precisam ler do disco pode travar.

Também pode ser que você tenha atingido um bug do kernel, ou algum outro problema de driver, ou tenha um bit defeituoso na memória RAM, ou tenha virtualmente qualquer outro hardware defeituoso. Se um driver bloqueado um recurso específico no kernel e, em seguida, acertar um bug ou erro e não conseguir desbloqueá-lo corretamente, qualquer outro driver ou chamada de sistema que tente obter esse bloqueio simplesmente será interrompido.

Pode não ser um bug no kernel. Você pode obter esse tipo de comportamento quando, por exemplo, usando as ferramentas lvm ou dmsetup para gerenciar discos. Ambos podem suspender um dispositivo, o que faz com que "qualquer E / S posterior a esse dispositivo seja adiada enquanto o dispositivo estiver suspenso". Programas que tentam acessar o dispositivo simplesmente bloqueiam o kernel. Você poderia acionar isso manualmente com "dmsetup suspend", ou eu vi um disco deixado em estado suspenso por acidente quando a ferramenta LVM encontrou um erro.

Se isso é uma coisa de uma vez, não se preocupe. Se isso acontecer novamente, tente anotar cuidadosamente a saída do kernel para que você possa rastrear sua causa. O primeiro despejo de memória será o mais importante. Se isso acontecer muito e você não puder obter a saída, considere usar um netconsole para enviar a saída do kernel diretamente para outra máquina.

    

Answer 2

Parar um processo é o que o kill faz. Acho que executar kill -9 PID e apenas esperar que ele tenha recursos suficientes para processar foi a resposta certa.

Se você acha que os processos estavam sobrecarregando a memória, você também pode chamar manualmente o killer da OOM:

echo f > /proc/sysrq-trigger