Por que meu servidor debian caiu?

2

Eu tenho um servidor debian recentemente instalado ontem à noite. Eu 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 web. Depois configurei um crontab (que roda a cada 10mins). Eu tive um problema semelhante antes (pensei reinstalar pode consertá-lo).

Após algumas horas, o servidor falha de alguma forma. Eu não consigo acessar o servidor, não consigo acessar a máquina via ssh, mas de alguma forma ainda funciona. Eu posso ver a máquina rodando na interface web do meu hoster. Ainda assim, como não consigo acessar nenhum serviço, preciso reiniciá-lo (por meio da interface da web fornecida pelo meu hoster).

Depois de reiniciá-lo, sempre verifiquei todos os logs em / var / log com registros de data e 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 é aquele do google 8.8.8.8. No entanto, isso acontece apenas às vezes e geralmente os serviços continuam funcionando depois disso. É por isso que acho que esta é uma questão diferente. Desativei o crontab após o último travamento e atualizo esta postagem se o problema for resolvido agora.

A outra coisa que me faz acreditar que o servidor não está totalmente travado é 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 da Web já tenha falhado (ou o que aconteceu nesse momento) em algum lugar entre 10:00 e 10:10 (no momento 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 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?

update: Usando o plog, o único evento perceptível em torno do tempo de falha (que estava entre 19:31 e 32) é o arquivo de log de um processo do 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
    
por Raphael 28.03.2014 / 13:22

1 resposta

0

O problema, na verdade, não era o próprio servidor. O servidor era um servidor privado virtual 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ória!

    
por 30.11.2015 / 23:05