Reparar problemas en el servicio web – Taller Linux

<img class="size-square wp-image-3670 alignleft" title="Servicio web" alt="Servicio web" src="http://www accutane capsules online.rdadmin.com/wp-content/uploads/2014/03/servidorweb-180×180.png” width=”180″ height=”180″ srcset=”https://www.rdadmin.com/wp-content/uploads/2014/03/servidorweb-180×180.png 180w, https://www.rdadmin.com/wp-content/uploads/2014/03/servidorweb-80×80.png 80w, https://www.rdadmin.com/wp-content/uploads/2014/03/servidorweb-36×36.png 36w, https://www.rdadmin.com/wp-content/uploads/2014/03/servidorweb-120×120.png 120w, https://www.rdadmin.com/wp-content/uploads/2014/03/servidorweb.png 256w” sizes=”(max-width: 180px) 100vw, 180px” />Uno de los usos más comunes de los servidores online es el de alojar sitios web. Esto es posible gracias a software que sirve contenido http entre otras cosas. En está entrada os explicaremos algunos trucos para poder detectar y reparar problemas en el servicio web que estén en sistemas GNU/Linux. Para simplificar nos centraremos en apache que es de los más usados.

Normalmente la primera noticia que tenemos cuando hay problemas en el servidor web es que los navegadores no son capaces visualizar los contenidos. Antes de entrar al servidor deberíamos revisar si el problema es de DNS y porque el nombre del dominio no resuelve a la Ip de nuestro servidor web. Esto se puede ver fácilmente usando  aplicaciones como ping,  host, nslookup dig, etc.. dependiendo de la que tengamos más a mano.

Si ya estamos seguros de que la DNS funciona y el dominio apunta a la ip del servicio web, deberemos acceder a este como administradores y tratar de averiguar y resolver cualquiera que sea el problema.

Antes de entrar al trapo, como primera información diremos que el protocolo http trabaja en el puerto 80 de nuestro servidor. Este es un dato importante ya que sabiéndolo podremos obtener fácilmente datos sobre los procesos que se estén ejecutando en el.

Una vez dentro, lo primero que podemos hacer es utilizar el comando “netstat” que muestra un listado de puertos y conexiones establecidas en nuestro servidor:

[root@server ~]# netstat -taupeln |grep LISTEN |grep :80
tcp    0     0 :::80     :::*     LISTEN   0     28682  7409/httpd

Como se aprecia, usando el comando junto con “grep”, para filtrar por “LISTEN” y “:80” nos muestra si hay algún proceso a la escucha en el puerto 80, y que utiliza el servicio “httpd”. Si quitásemos el “|grep LISTEN” del comando nos mostraría además las conexiones que siguen activas en ese puerto, entre ellas podemos encontrar conexiones establecidas, en espera o pendientes de cerrarse.

Además, disponemos también de un comando llamado “lsof” que nos puede mostrar aun más información referente a usuarios y a número de procesos corriendo. Este comando muestra información sobre los ficheros abiertos en el sistema Linux, dado que en Linux todo funciona a través de ficheros pues nos es muy útil. En este caso necesitamos indicarle que busque ficheros abiertos relacionados con el puerto 80 y esto lo haremos especificando  “-i :80”, dentro del sistema estando como usuarios administradores:

[root@server ~]# lsof -i :80
 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
 httpd 2158 root 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
 httpd 20311 apache 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
 httpd 22408 apache 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
 httpd 24987 apache 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
 httpd 25426 apache 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
 httpd 25539 apache 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
 httpd 31734 apache 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
[root@server ~]#

Esto de arriba es una salida normal de un servidor donde nadie está mirando las páginas alojadas. En ella podemos ver como el usuario que ejecuta los procesos es “apache”, que hay un proceso padre y 6 procesos hijos esperando a que entren peticiones para servirles el contenido. Si alguien mirase alguna página aparecería más información donde ahora aparece “LISTEN”, indicando el origen de la conexión entre otras cosas.

Si en nuestro servidor vemos que no hay procesos corriendo en el puerto 80 con cualquiera de los comandos anteriores, es indicativo de que el servicio web no está funcionando como debe y por tanto tendremos que intentar arrancarlo de nuevo. Esto dependiendo de que distribución de Linux utilicemos se hará utilizando un nombre o otro, en las distribuciones basadas en Redhat como Centos se hace con “httpd” y en las basadas en Debian  como Ubuntu, con “apache2”:

[root@server ~]# service httpd start
Starting httpd:                                            [  OK  ]
[root@server ~]#

En nuestro caso usamos httpd porque es un Centos, y como se ve el servidor web ha arrancado correctamente, con lo que solo nos quedaría comprobar que ahora si hay procesos corriendo y tratar de visualizar las webs de nuevo en el navegador.

En el caso que no arrancase es posible que nos muestre un mensaje de error que habría que analizarlo en detalle para determinar exactamente que ocurre, ya que hay muchas posibilidades. También deberíamos mirar en el log de errores para ver si ha salido algún mensaje indicativo. Esto lo podemos hacer con el comando cat o tail o con cualquier editor de textos de consola, como vim o nano, o emacs.

Una aplicación muy útil de las anteriormente mencionadas es “tail” ya que con el parámetro “-f” detrás nos permite ver los logs a tiempo real, por ejemplo:

tail -f /var/log/httpd/error_log

Si esto lo dejamos corriendo en una consola y con la otra tratamos de arrancar el servicio, o accedemos al navegador podremos ver los errores a tiempo real, lo cual será muy útil.

En ocasiones el servidor web parece estar arrancado y funcionando normalmente con sus procesos a la escucha, pero aun así las webs no funcionan correctamente y no muestran ningún contenido en el navegador.

En estos casos para ver que sucede lo prioritario como hemos indicado antes es mirar el log de errores, que normalmente mostrará información detallada de los problemas que impiden el funcionamiento. Una vez mostrado el error, si no sabemos de que se trata, lo normal es utilizar un buscador como Google para obtener información sobre este error y alguna forma de solucionarlo. Si aun así no aparece ningun mensaje lo que habría que hacer es parar todas las instancias del servidor web y lanzarlo en modo debug:

httpd -e DEBUG

Con esto si que deberíamos poder ver cualquier error interno para ayudarnos en su resolución. En cualquier caso si después de haber seguido todos estos pasos no consigues hacer funcionar tu servidor web te recomendamos que te pongas en manos de profesionales que puedan resolver la incidencia de forma rápida y eficiente.

Para finalizar vamos a poner un listado de los errores más comunes que nos podemos encontrar a la hora de levantar un servicio web caído y algunas ideas de como solucionarlos. Los errores que pueden salir en el log cuando el problema es de la configuración web o el código los dejamos para otra entrada posterior.

1. “make_sock: could not bind to address 0.0.0.0:80 no listening sockets available”

Si al arrancar el servicio web aparece este error probablemente es que ya se encuentre funcionando ya que hay algo a la escucha en el puerto  80. Si tenemos problemas podemos probar de detenerlo primero con un “service httpd/apache2 stop”, pero si aun así sigue saliendo el mismo error deberíamos matar el proceso que está ocupando el puerto 80, sacando primero el número pid con el comando lsof o netstat arriba descritos y usando el comando “kill -s 9 “pid” para forzarlo a pararse.

2. “No such file or directory: apache2: could not open error log file /var/log/apache2/error.log”

Con este error el servidor web nos indica que al arrancar no ha podido escribir en el log que tiene asignado en su configuración, bien porque la carpeta no existe, porque no puede crear el fichero o porque el fichero existe pero los permisos/usuarios no son los correctos. Para resolverlo hay que analizar todos estos factores y permitir que el usuario del servidor web pueda escribir en ese fichero y volver a lanzar el proceso.

3. “Starting httpd: Syntax error on line xxx of /etc/httpd/conf/httpd.conf:  DocumentRoot must be a directory”

A veces el error nos redirige a un punto exacto de la configuración del servicio web. En ese caso deberemos revisar el fichero de configuración en cuestión, y analizar que puede fallar exactamente en la linea indicada. En este caso  el “DocumentRoot” que es la raíz del servidor web no era accesible por este, siendo la solución similar a la del punto 2.

——————————————————————————————————

Y hasta aquí hemos llegado en esta entrada, si nos surgen más errores comunes los añadiremos junto con su explicación. Desde Rdadmin os instamos a que nos consultéis cualquier problema o duda que tengáis escribiendo en el blog o a nuestro email de contacto. Os ofreceremos asesoramiento sin ningún compromiso.