Este me deixou perplexo. Eu tenho o Ubuntu 14.04, há 3 dias (10/20/2014) ele começou a ficar lento.
Eu o reproduzi abrindo o gedit e fechando o gedit. Quando o problema está ativo, leva cerca de 2 segundos para fechar um arquivo vazio, enquanto sem o problema isso é sempre instantâneo - afeta todo o resto de maneira semelhante.
top não relata nenhuma atividade incomum quando ocorre o congelamento, htop o mesmo, iotop o mesmo também.
O problema só surge após 30 minutos de tempo de atividade, posso garantir que aos 29 minutos de tempo de atividade não consegui reproduzi-lo, aos 31 minutos de tempo de atividade consegui reproduzir isso de forma consistente (usando o método acima, nenhum aplicativo foi iniciado além do terminal e htop) e gerenciado repetir isso 4 ou 5 vezes (desligando, inicializando e esperando meia hora - o que foi agradável).
O problema persiste mesmo após as reinicializações, mas pode ser redefinido desligando e ligando novamente. Que parte do Ubuntu mantém o estado após as reinicializações, mas não os desligamentos?
Os logs relevantes para este período são syslog, auth.log e Xorg.0.log (examinando o conteúdo de /var/log para o tempo modificado no intervalo especificado)
registro de sistema:
Oct 22 17:21:36 raiden NetworkManager[1102]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Oct 22 17:39:01 raiden CRON[3284]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Oct 22 18:09:01 raiden CRON[3370]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
registro de autenticação:
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session closed for user root
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session closed for user root
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session closed for user root
Xorg.0.log: (provavelmente eu acabei de acordar o computador)
[ 3466.727] (II) intel(0): switch to mode [email protected] on LVDS1 using pipe 0, position (0, 900), rotation normal, reflection none
[ 3466.880] (II) intel(0): switch to mode [email protected] on VGA1 using pipe 1, position (0, 0), rotation normal, reflection none
Nada disso indica nada de ruim e as etapas subsequentes para reproduzir o problema não indicam alterações nos logs, portanto, provavelmente eram apenas logs inocentes.
Presumo que haja três fontes possíveis para esse problema:
Instalação de software: instalei algo duvidoso
Eu fiz:
- história | grep apt-get' - nenhuma instalação nesse período
- Analisei o histórico do gerenciador de pacotes sinápticos - nada naquele período de tempo
- Histórico do centro de software - a última atualização foi várias semanas antes (houve um problema de dependência, então eu não fazia nenhuma atualização há algum tempo)
- Instalei o Skype para Ubuntu nesse período, mas não há indicação de que seja causado pelo Skype (removi-o mesmo assim)
Cron job dando errado
Verifiquei cronjobs no crontab, /etc/cron.d /etc/cron.daily e de hora em hora, nada indicando que há algo lá, apenas um cron job PHP ocorre a cada 30 minutos, mas se fosse cron, faria isso em determinados pontos, 24 horas por dia, não 30 minutos após a inicialização.
A análise de novos processos que foram iniciados entre o estado de não desaceleração e o estado de desaceleração sugere que nenhum novo processo foi iniciado (o primeiro teste mostrou um thread kworker, mas é provável que seja apenas uma coincidência). Presumo que isso deva significar que foi um processo existente que o desencadeou ou outra coisa.
Programas maliciosos
Devido à sua indefinição e à misteriosa ausência de 30 minutos do problema (30 minutos parece um período de tempo escolhido pelo homem), comecei a pensar que poderia ser algum tipo de malware, por mais improvável que fosse (não tinha feito uma atualização para um tempo e tem algumas portas abertas). Então executei o rkhunter (localizador de rootkit), mas nada desagradável foi encontrado.
Outras coisas que tentei:
- Desmarcando certos componentes do Compiz - sem alterações
- Reiniciando o compiz - sem alterações
- Desmarcando todos os componentes do compiz - sem alterações (exceto eu lutando para tornar o computador utilizável novamente)
- Tocar vários instrumentos musicais enquanto espera o tempo de atividade chegar a 30 minutos e depois observar os resultados de top e htop em busca de quaisquer alterações suspeitas - nada de estranho
Alguém já teve algo semelhante a isso acontecendo com eles ou poderia me indicar a direção certa, se você fizer isso, apertarei o botão de votação repetidamente em sua resposta (vou me certificar de que seja um número ímpar)
Responder1
Existem algumas maneiras de configurar o cron para executar um trabalho 30 minutos após a inicialização. Jenkins faz isso hash da função e usando, H/30 * * * *por exemplo. Também pode ser um thread dormindo por 30 minutos e gerando um processo silencioso de CPU Killer.
Algumas ideias aí:
Você tentou o htop como root? Alguns processos podem ser invisíveis, vi isso especialmente no Debian.
Você tentou sair/fazer login novamente quando o problema ocorreu? Pode ser o gerenciador de janelas ou um problema de sessão.
Se o logout/login não funcionar, você pode tentar reiniciar o gerenciador de sessões. Eu acho que é lightdm por padrão, então sudo service lightdm restartdeveria fazê-lo.
Responder2
Isto foi causado porDados INTELIGENTESsendo habilitado para a unidade em questão.
Desativar os dados SMART resolveu isso:
sudo smartctl --smart=off /dev/sda
Presumivelmente, ele repetiu algum tipo de autoteste interno 30 minutos depois que o disco girou e entrou em loop; como isso estava na camada de hardware, o resto do computador não sabia disso, portanto, não pude ver nenhum processo em particular responsável pelo bloqueio de IO e nenhum processo consumindo recursos.