Suspensão do servidor Ubuntu 11.04 devido ao consumo excessivo da CPU do landscape-sysinfo

Question

Estou executando um servidor básico (baseado no Ubuntu 11.04) em uma micro instância do Amazon EC2, cuja finalidade é simplesmente coordenar as atividades de alguns servidores da Web. A máquina funcionou bem por algumas semanas, mas agora está pendente com freqüência com seu CPU redefinido em 100%.

Eu entrei na máquina por SSH e executei um top , que revelou que o processo landscape-sysinfo foi o perpetrador consumindo todos os recursos do sistema. Um pstree revelou onde estava:

init─┬─atd
     ├─cron
     ├─dhclient3
     ├─dovecot─┬─2*[dovecot-auth]
     │         ├─3*[imap-login]
     │         └─3*[pop3-login]
     ├─6*[getty]
     ├─master─┬─pickup
     │        └─qmgr
     ├─mountall
     ├─mysqld───11*[{mysqld}]
     ├─rsyslogd───3*[{rsyslogd}]
     ├─sshd─┬─sshd───sshd───bash
     │      ├─sshd───sshd───bash───top
     │      ├─sshd───sshd───bash───pstree
     │      └─sshd───sh───run-parts───50-landscape-sy───landscape-sys+
     ├─udevd───2*[udevd]
     ├─upstart-socket-
     ├─upstart-udev-br
     └─vsftpd

O processo incorreto está listado aqui como o último filho de sshd . Se eu matar manualmente landscape-sysinfo , a máquina retornará ao normal - até que o processo reapareça espontaneamente, geralmente alguns instantes depois. (Eu posso "atestar" os outros processos sshd na árvore acima. Eles eram legítimos.)

Eu não tenho idéia do porque landscape-sysinfo está gerando a si mesmo aleatoriamente. Eu não tenho idéia do porque é filho de sshd .

Eu obviamente não estou muito entusiasmado em ter processos SSH em execução na minha máquina que não posso explicar. Inicialmente, eu temia uma violação / trojan / backdoor, então eu corri chkrootkit e rkhunter , mas ambos apareceram limpos.

Alguém tem ideia do que poderia estar causando esse processo? Alguma idéia de como impedi-lo de renascer?

    

Answer 1

Eu descobri a causa real do problema há algum tempo e imaginei que deveria documentá-lo aqui para outros que possam ter problemas semelhantes. A causa raiz acabou por ser mais complicada e complicada do que eu esperava inicialmente.

Em suma, run-parts estava funcionando bem o tempo todo. Seu descontrole foi apenas o sintoma de um problema diferente. A cadeia de falhas parecia algo assim:

1) Em uma máquina totalmente diferente , o lsyncd (um utilitário de sincronização de arquivos baseado em rsync ) estava funcionando mal por razões além da nossa preocupação aqui. Porém, nossa preocupação é que lsyncd estava tentando sincronizar arquivos contra essa micro instância (que manifestou os problemas) pelo SSH.

2) Como o lsyncd estava realizando dezenas de conexões simultâneas em SSH, cada uma aparentemente estava sendo saudada com o banner de login do SSH landscape-sysinfo O Ubuntu fornece por padrão. Isso explica o que é landscape-sysinfo e porque é filho do SSH. Parece que run-parts foi o culpado, mas na verdade a questão era que a máquina estava sendo bombardeada com conexões SSH.

3) Exacerbando o problema foi que esta é uma micro instância no EC2, e descobri que a Amazon limita drasticamente as micro-instâncias cujo consumo de CPU está constantemente acima de um certo limite. ( Para uma excelente explicação dos detalhes, consulte Divagações de Greg . Muito obrigado ao Greg por esse artigo!)

Assim, a máquina rodou devagar por alguns momentos enquanto estava sendo bombardeada com conexões SSH, e depois ficou inutilmente lenta após o início da aceleração.

Mistério solucionado!

    

Answer 2

É uma tarefa cron regularmente planejada que reúne dados de desempenho.

Veja aqui para instruções de remoção (leves). Para apenas removê-lo completamente se você não se importa com a coleta de dados, remova o pacote (se ele permitir) ou simplesmente localize a entrada crontab para ele e comente.