Iniciar y Parar el servidor Apache

Idiomas disponibles: de | en | es | fr | ja | ko | tr

Este documento explica como iniciar y parar el servidor Apache en sistemas tipo Unix. Los usuarios de Windows NT, 2000 y XP deben consultar la sección Ejecutar Apache como un servicio y los usuario de Windows 9x y ME deben consultar Ejecutar Apache como una Aplicación de Consola para obtener información sobre como controlar Apache en esas plataformas.

Introducción
Parar Ahora Apache
Reinicio "Graceful" o elegante
Reiniciar Apache
Apándice: señales y race conditions

Consulte también

Introducción ¶

Para parar y reiniciar Apache, hay que enviar la señal apropiada al proceso padre httpd que se está ejecutando. Hay dos maneras de enviar estas señales. En primer lugar, puede usar el comando de Unix kill que envía señales directamente a los procesos. Puede que tenga varios procesos httpd ejecutándose en su sistema, pero las señales deben enviarse solamente al proceso padre, cuyo PID está especificado en la directiva PidFile. Esto quiere decir que no debe necesitar enviar señales a ningún proceso excepto al proceso padre. Hay tres señales que puede enviar al proceso padre: TERM, USR1 HUP, y WINCH, que van a ser descritas a continuación.

Para enviar una señal al proceso padre debe escribir un comando como el que se muestra en el ejemplo:

kill -TERM `cat /usr/local/apache2/logs/httpd.pid`

La segunda manera de enviar señales a los procesos httpd es usando las opciones de línea de comandos -k: stop, restart, y graceful y graceful-stop, como se muestra más abajo. Estas opciones se le pueden pasar al binario httpd, pero se recomienda que se pasen al script de control apachectl, que a su vez los pasará a httpd.

Después de haber enviado las señales que desee a httpd, puede ver como progresa el proceso escribiendo:

tail -f /usr/local/apache2/logs/error_log

Modifique estos ejemplos para que coincidan con la configuración que tenga especificada en las directivas ServerRoot y PidFile en su fichero principal de configuración.

Parar Ahora Apache ¶

Señal: TERM: apachectl -k stop

Enviar las señales TERM o stop al proceso padre hace que se intenten eliminar todos los procesos hijos inmediatamente. Esto puede tardar algunos segundos. Una vez que hayan terminado todos los procesos hijos, terminará el proceso padre. Cualquier petición en proceso terminará inmediatamente, y ninguna petición posterior será atendida.

Reinicio "Graceful" o elegante ¶

Señal: USR1: apachectl -k graceful

Las señales USR1 o graceful hacen que el proceso padre indique a sus hijos que terminen después de servir la petición que están atendiendo en ese momento (o de inmediato si no están sirviendo ninguna petición). El proceso padre lee de nuevo sus ficheros de configuración y vuelve a abrir sus ficheros log. Conforme cada hijo va terminando, el proceso padre lo va sustituyendo con un hijo de una nueva generación con la nueva configuración, que empiezan a servir peticiones inmediatamente.

En algunas plataformas que no permiten usar USR1 para reinicios graceful, puede usarse una señal alternativa (como WINCH). También puede usar apachectl graceful y el script de control enviará la señal adecuada para su plataforma.

Apache está diseñado para respetar en todo momento la directiva de control de procesos de los MPM, así como para que el número de procesos e hilos disponibles para servir a los clientes se mantenga en los valores adecuados durante el proceso de reinicio. Aún más, está diseñado para respetar la directiva StartServers de la siguiente manera: si después de al menos un segundo el nuevo hijo de la directiva StartServers no ha sido creado, entonces crea los suficientes para que se atienda el trabajo que queda por hacer. Así, se intenta mantener tanto el número de hijos adecuado para el trabajo que el servidor tenga en ese momento, como respetar la configuración determinada por los parámetros de la directiva StartServers.

Los usuarios del módulo mod_status notarán que las estadísticas del servidor no se ponen a cero cuando se usa la señal USR1. Apache fue escrito tanto para minimizar el tiempo en el que el servidor no puede servir nuevas peticiones (que se pondrán en cola por el sistema operativo, de modo que se no se pierda ningún evento), como para respetar sus parámetros de ajuste. Para hacer esto, tiene que guardar el scoreboard usado para llevar el registro de los procesos hijo a través de las distintas generaciones.

El mod_status también usa una G para indicar que esos hijos están todavía sirviendo peticiones previas al reinicio graceful.

Actualmente no existe ninguna manera de que un script con un log de rotación usando USR1 sepa con seguridad que todos los hijos que se registraron en el log con anterioridad al reinicio han terminado. Se aconseja que se use un retardo adecuado después de enviar la señal USR1 antes de hacer nada con el log antiguo. Por ejemplo, si la mayor parte las visitas que recibe de usuarios que tienen conexiones de baja velocidad tardan menos de 10 minutos en completarse, entonces espere 15 minutos antes de hacer nada con el log antiguo.

Si su fichero de configuración tiene errores cuando haga el reinicio, entonces el proceso padre no se reiniciará y terminará con un error. En caso de un reinicio graceful, también dejará a los procesos hijo ejecutándose mientras existan. (Estos son los hijos de los que se está saliendo de forma graceful y que están sirviendo sus últimas peticiones.) Esto provocará problemas si intenta reiniciar el servidor no será posible conectarse a la lista de puertos de escucha. Antes de reiniciar, puede comprobar que la sintaxis de sus ficheros de configuración es correcta con la opción de línea de comandos -t (consulte httpd). No obstante, esto no garantiza que el servidor se reinicie correctamente. Para comprobar que no hay errores en los ficheros de configuración, puede intentar iniciar httpd con un usuario diferente a root. Si no hay errores, intentará abrir sus sockets y logs y fallará porque el usuario no es root (o porque el httpd que se está ejecutando en ese momento ya está conectado a esos puertos). Si falla por cualquier otra razón, entonces casi seguro que hay algún error en alguno de los ficheros de configuración y debe corregir ese o esos errores antes de hacer un reinicio graceful.

Reiniciar Apache ¶

Señal: HUP: apachectl -k restart

El envío de las señales HUP o restart al proceso padre hace que los procesos hijo terminen como si le enviáramos la señal TERM, para eliminar el proceso padre. La diferencia está en que estas señales vuelven a leer los archivos de configuración y vuelven a abrir los ficheros log. Se genera un nuevo conjunto de hijos y se continúa sirviendo peticiones.

Los usuarios del módulo mod_status notarán que las estadísticas del servidor se ponen a cero cuando se envía la señal HUP.

Si su fichero de configuración contiene errores, cuando intente reiniciar, el proceso padre del servidor no se reiniciará, sino que terminará con un error. Consulte más arriba cómo puede solucionar este problema.

Apándice: señales y race conditions ¶

Con anterioridad a la versión de Apache 1.2b9 había varias race conditions implicadas en las señales para parar y reiniciar procesos (una descripción sencilla de una race condition es: un problema relacionado con el momento en que suceden las cosas, como si algo sucediera en momento en que no debe, y entonces el resultado esperado no se corresponde con el obtenido). Para aquellas arquitecturas que tienen el conjunto de características "adecuadas", se han eliminado tantas race conditions como ha sido posible. Pero hay que tener en cuenta que todavía existen race conditions en algunas arquitecturas.

En las arquitecturas que usan un ScoreBoardFile en disco, existe la posibilidad de que se corrompan los scoreboards. Esto puede hacer que se produzca el error "bind: Address already in use" (después de usarHUP) o el error "long lost child came home!" (después de usar USR1). En el primer caso se trata de un error irrecuperable, mientras que en el segundo, solo ocurre que el servidor pierde un slot del scoreboard. Por lo tanto, sería aconsejable usar reinicios graceful, y solo hacer reinicios normales de forma ocasional. Estos problemas son bastante complicados de solucionar, pero afortunadamente casi ninguna arquitectura necesita un fichero scoreboard. Consulte la documentación de la directiva ScoreBoardFile para ver las arquitecturas que la usan.

Todas las arquitecturas tienen una pequeña race condition en cada proceso hijo implicada en la segunda y subsiguientes peticiones en una conexión HTTP persistente (KeepAlive). Puede ser que el servidor termine después de leer la línea de petición pero antes de leer cualquiera de las cabeceras de petición. Hay una solución que fue descubierta demasiado tarde para la incluirla en versión 1.2. En teoría esto no debe suponer ningún problema porque el cliente KeepAlive ha de esperar que estas cosas pasen debido a los retardos de red y a los timeouts que a veces dan los servidores. En la practica, parece que no afecta a nada más en una sesión de pruebas, un servidor se reinició veinte veces por segundo y los clientes pudieron navegar sin problemas por el sitio web sin encontrar problemas ni para descargar una sola imagen ni encontrar un solo enlace roto.