Eu tenho um servidor Debian recentemente instalado ontem à noite. Usei uma imagem chamada debian-7.0-amd64-minimal do meu hoster. Acabei de instalar o apache2, mysql, php, vim, lynx e configurei algumas páginas da web. Depois configurei um crontab (que roda a cada 10 minutos). Eu tive um problema semelhante antes (pensei que a reinstalação poderia resolver o problema).
Depois de algumas horas, o servidor trava de alguma forma. Não consigo acessar o servidor web, não consigo acessar a máquina via ssh, mas de alguma forma ela ainda funciona. Posso ver a máquina rodando na interface web do meu hoster. Mesmo assim, como não consigo acessar nenhum serviço, tenho que reiniciá-lo (através da interface web fornecida pelo meu hoster).
Depois de reiniciá-lo, sempre verifiquei todos os logs em/var/log com carimbos de data/hora relevantes. No entanto, há apenas um erro esporádico
[Fri Mar 28 12:40:17 2014] [error] [client x.x.x.x] PHP Warning: file_get_contents(http://www.bloomberg.com/quote/DAX:IND): failed to open stream: php_network_getaddresses: getaddrinfo failed: Name or service not known
Isso é causado por um script php chamado via crontab (uma página da web é invocada usando o lynx). O servidor DNS é o do google 8.8.8.8. No entanto, isso acontece apenas algumas vezes e normalmente os serviços continuam funcionando depois disso. É por isso que acho que este é um problema diferente. Desativei o crontab após a última falha e atualizo esta postagem se o problema for resolvido agora.
A outra coisa que me faz acreditar que o servidor não travou totalmente é que esses crontabs ainda continuam funcionando
Mar 28 10:00:01 aryx /USR/SBIN/CRON[10947]: (root) CMD (lynx -dump http://[webpage]/cron/cronjob.php)
Mar 28 10:00:06 aryx /USR/SBIN/CRON[10946]: (CRON) info (No MTA installed, discarding output)
Mar 28 10:09:01 aryx /USR/SBIN/CRON[11068]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Mar 28 10:10:01 aryx /USR/SBIN/CRON[11088]: (root) CMD (lynx -dump http://[webpage]/cron/cronjob.php)
Mar 28 10:10:21 aryx /USR/SBIN/CRON[11087]: (CRON) info (No MTA installed, discarding output)
Mar 28 10:20:01 aryx /USR/SBIN/CRON[11221]: (root) CMD (lynx -dump http://[webpage]/cron/cronjob.php)
Mar 28 10:20:21 aryx /USR/SBIN/CRON[11220]: (CRON) info (No MTA installed, discarding output)
mesmo que o servidor web já tenha travado (ou o que quer que tenha travado naquele horário) em algum lugar entre 10h e 10h10 (horário em que a próxima chamada do cron foi executada)
[webpage]:80 [ip-address] - - [28/Mar/2014:09:50:01 +0100] "GET /cron/cronjob.php HTTP/1.0" 200 208 "-" "Lynx/2.8.8dev.12 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/2.12.18"
[webpage]:80 [ip-address] - - [28/Mar/2014:10:00:01 +0100] "GET /cron/cronjob.php HTTP/1.0" 200 208 "-" "Lynx/2.8.8dev.12 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/2.12.18"
[webpage]:80 [ip-address] - - [28/Mar/2014:12:00:02 +0100] "GET /cron/cronjob.php HTTP/1.0" 200 208 "-" "Lynx/2.8.8dev.12 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/2.12.18"
A única irregularidade, porém, também ocorre antes das 10h
Mar 28 09:39:01 aryx /USR/SBIN/CRON[10658]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)*
Alguma sugestão do que poderia estar errado?
atualizar: Usando o plog, o único evento perceptível próximo ao horário do travamento (que ocorreu entre 19h31 e 32h) é o arquivo de log de um processo Apache:
3-28 19:31 S 20 0s 1 185.34MB 7.46MB 96.2% 1012kB 16.66MB 17.73MB 429 0
3-28 19:32 S 20 0s 1 187.50MB 9.68MB 89.1% 1804kB 16.79MB 17.86MB 1281 0
3-28 19:33 S 20 0s 1 187.50MB 9.68MB 89.1% 1804kB 16.79MB 17.86MB 1281 0
Responder1
Na verdade, o problema não era o servidor em si. O servidor era um servidor virtual privado e tinha um IP atribuído que também era usado por outro servidor na rede. É por isso que houve alguns problemas de conectividade aleatórios!