Ayer por la tarde instalé un servidor Debian recién instalado. Utilicé una imagen llamada debian-7.0-amd64-minimal de mi proveedor de alojamiento. Acabo de instalar apache2, mysql, php, vim, lynx y configuré algunas páginas web. Luego configuré un crontab (que se ejecuta cada 10 minutos). Tuve un problema similar antes (pensé que reinstalar podría solucionarlo).
Después de unas horas, el servidor falla de alguna manera. No puedo acceder al servidor web, no puedo acceder a la máquina a través de ssh pero de alguna manera todavía funciona. Puedo ver la máquina ejecutándose en la interfaz web de mi proveedor de alojamiento. Aún así, como no puedo acceder a ningún servicio, tengo que reiniciarlo (a través de la interfaz web proporcionada por mi proveedor de alojamiento).
Después de reiniciarlo, siempre verifiqué todos los registros en /var/log que tuvieran marcas de tiempo relevantes. Sin embargo, sólo hay un error 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
Esto se debe a un script php llamado a través de crontab (se invoca una página web usando lynx). El servidor DNS es el de Google 8.8.8.8. Sin embargo, esto sucede sólo a veces y, por lo general, los servicios continúan funcionando después de eso. Por eso supongo que este es un tema diferente. Deshabilité el crontab después del último bloqueo y actualizo esta publicación si el problema se resuelve solo ahora.
La otra cosa que me hace creer que el servidor no falla del todo es que esos crontabs siguen 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)
a pesar de que el servidor web ya falló (o lo que sea que falló en ese momento) en algún momento entre las 10:00 y las 10:10 (momento en el que se ejecutó la siguiente llamada cron)
[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"
Sin embargo, la única irregularidad también ocurre antes de las 10 a.m.
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)*
¿Alguna sugerencia de qué podría estar mal?
actualizar: Usando plog, el único evento notable alrededor del momento del bloqueo (que fue entre las 19:31 y 32) es el archivo de registro de un proceso de 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
Respuesta1
En realidad, el problema no era el servidor en sí. El servidor era un servidor privado virtual y tenía una IP asignada que también era utilizada por otro servidor de la red. ¡Es por eso que hubo algunos problemas de conectividad aleatorios!