PID fugiu com todos os nossos MEM e SWAPPED hard - OSSEC RHEL

Question

Perdoe-me pela duração desta pergunta ... é principalmente detalhes ... apenas tente seguir se você também gosta de ler arquivos de registro ... ou tomar café.

Vou apresentar as perguntas primeiro:

1) como diabos fez um processo nano     disparar com base no que eu disse     abaixo

2) Como o nano conseguiu tirar isso?     muito recurso

3) trabalhando com reinicializações do ossec     certamente não é uma coincidência assim é     relacionado?

Este é um ambiente Red Hat 4.1.2-46 XEN, três membros de cluster. Atualizamos nosso código de monitoramento de furacão manualmente em 17 de janeiro às 11h34. Dois arquivos foram alterados (usando nano) enquanto ossec estava em execução :

preloaded-vars.conf
ossec.conf

ossec foi então reiniciado e, em seguida, o usuário root efetuou o logoff.

Infelizmente, os três servidores ficaram offline (ainda tinham ssh) porque um processo nano acabou (imagino que isso teria acontecido se eu tivesse usado VI - então o tipo de editor não está em questão). Estranhamente, nenhum crons iniciou o serviço nano e ninguém estava logado no servidor no momento, e tenho certeza que eu fechei corretamente o nano. Antes de eu matar o PID, top me deu a seguinte opinião:

Mem:  28359680k total, 28325064k used,    34616k free,     3424k buffers
Swap:  4194296k total,  4194296k used,        0k free,    70208k cached
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
26351 root      18   0 29.7g  25g  784 R 100.1 95.6   4424:38 nano

Observação: o editor nano consumiu ~ 28 GB de RAM.

Demorou pouco mais de três dias para que isso derrubasse nossos servidores. Eu encontrei outra coisa antes de matar o processo. Observe que o processo nano começou duas horas depois de o arquivo ter sido editado pela primeira vez e o logoff do root efetuado. Observe que o tty =?.

# ps -ef | grep nano
root      7836  7689  0 13:19 pts/5    00:00:00 grep nano
root     26351     1 99 Jan17 ?        3-01:44:46 nano /opt/ossec/etc/ossec.conf

Felizmente, depois que eu matei o PID, tive:

Mem:  28359680k total,  1189924k used, 27169756k free,     4584k buffers
Swap:  4194296k total,   260284k used,  3934012k free,   104352k cached

Primeiro, esperei descobrir que o status do processo seria stopped ou traced , mas era running (veja o R antes do% de uso da CPU)

Notas adicionais. O arquivo preloaded-vars.conf foi criado a partir de um arquivo .tar (portanto, o 1000: 1000). Foi editado pela raiz. O arquivo .sav foi criado quando eu matei nano (e é menor que o arquivo principal). Em dois dos servidores Xen, o nano não parou de editar o arquivo preloaded-vars.conf e, no terceiro nano, foi gravado editando o arquivo ossec.conf. Nenhum ossec.conf.save foi criado quando o nano foi morto.

-rwxr-xr-x  1 1000 1000  2918 Jan 17 11:04 preloaded-vars.conf
-rw-------  1 root root  2909 Jan 20 13:13 preloaded-vars.conf.save

Outras descobertas: Eu descobri que se eu abro o arquivo preloaded-vars.conf e depois de outro terminal mata o pid, o comportamento padrão do nano é criar um arquivo preloaded-vars.conf.save quando ele recebe uma mensagem SIGHUP ou SIGTERM. Ainda não entendi o que o levou a sair dos trilhos para começar.

    

Answer 1

Bem, a resposta para (2) é provavelmente "Você não tem nenhum limite de recursos configurado" - confira ulimit para resolver esse problema.

Não há pistas sobre os outros.