Parando y rearrancando Apache

Este documento cubre el arranque y parada de Apache sobre Unix únicamente. Usuarios de Windows deberán consultar Enviando señales a Apache mientras está corriendo.

Usted verá varios ejecutables httpd corriendo en el sistema, pero no debe enviar señales a ninguno excepto al padre, cuyo PID está en el Archivo PID. Nunca necesitará enviar señales a ningún proceso excepto al padre. Hay tres señales que puede enviar al padre: TERM, HUP, y USR1, las cuales serán descritas en un momento.

Para enviar una señal al padre deberá ejecutar un comando como:

    kill -TERM `cat /usr/local/apache/logs/httpd.pid`
Puede leer acerca del progreso ejecutando:
    tail -f /usr/local/apache/logs/error_log
Modifique esos ejemplos para que concuerden con sus configuraciones ServerRoot y PidFile.

Apache 1.3 provee un script llamado apachectl el cual puede ser usado para arrancar, parar y rearrancar Apache. Éste puede necesitar un poco de personalización para su sistema. Vea los comentarios al principio de dicho archivo de comandos.

Señal TERM: terminar ahora

Enviando la señal TERM al proceso padre causa de inmediato matar a todos los procesos hijo. Este puede tomar varios segundos en completar la tarea. Luego el proceso padre en sí termina. Cualquier requerimiento en progreso es terminado, y ningún nuevo requerimiento es servido.

Señal HUP: reiniciar ahora

Enviando la señal HUP al proceso padre provoca que todos los hijos sean terminados como con la señal TERM pero el padre no termina. Éste relee sus archivos de configuración y reabre los archivos log. Luego arranca una nueva serie de procesos hijo y continúa atendiendo peticiones.

Usuarios del módulo de estado status module podrán notar que las estadísticas del servidor son establecidas a cero cuando es enviada una señal HUP.

Nota: Si sus archivos de configuración contienen errores, el proceso padre no rearrancará cuando se reinicie el servidor. Éste saldrá con un error. Vea más abajo el método para evitarlo.

Señal USR1: rearranque agraciado

Nota: antes de la versión 1.2b9 este código era un poco inestable y no se recomendaba su uso.

La señal USR1 causa que el proceso padre notifique a los procesos hijos que terminen el requerimiento actual (o salgan inmediatamente si no están atendiendo un requerimiento). El padre relee sus archivos de configuración y reabre los archivos log. Como cada hijo muere, el padre los reemplaza con hijos con la nueva generación de configuración, los cuales comienzan a servir los nuevos requerimientos inmediatamente.

Este código está diseñado para respetar las configuraciones de MaxClients, MinSpareServers, and MaxSpareServers. Mas aún, este respeta StartServers de la siguiente manera: si después de un segundo al menos, los nuevos hijos de StartServers no han sido creados, entonces crea los suficientes para continuar. Esto es para enfatizar que el código intenta mantener tanto el número de hijos apropiados para la carga actual del servidor como también el parámetro de StartServers.

Usuarios del módulo de estado status module podrán notar que las estadísticas del servidor no son establecidas a cero cuando se envía una señal USR1. El código fue escrito para minimizar el tiempo en el cual el servidor es incapaz de atender nuevos requerimientos (éstos son encolados por el sistema operativo, por lo cual no se pierden bajo ninguna circunstancia) y para respetar sus ajustes de configuración. Para hacerlo, éste debe mantener el scoreboard; usado para seguir la pista de todos los procesos hijos en todas las generaciones.

El módulo de estado también usará una G para indicar aquellos hijos que todavía están sirviendo requerimientos previo al rearranque agraciado.

Al presente no hay forma de saber, mediante un script de rotación de archivos log usando USR1, si efectivamente la preescritura a los log de todos los hijos ha finalizado. Le sugerimos que use una espera adecuada luego de enviar la señal USR1 antes que haga algo con el archivo log antiguo. Por ejemplo, si la mayoría de sus hits toman menos de 10 minutos en completarse para usuarios con enlaces de banda ancha reducida, debería esperar 15 minutos antes de hacer algo con sus antiguos logs.

Nota: Si su archivo de configuración tiene errores cuando envía un señal de reinicio, el padre podría no arrancar y salir con un mensaje de error apropiado. En el caso del reinicio agraciado, este podría incluso dejar hijos ejecutándose cuando el padre sale (éstos son los hijos que están "saliendo agraciadamente" manejando su último requerimiento.) Esto podría causar problemas si intenta reiniciar el servidor --podría no ser capaz de escuchar los puertos. Antes de reiniciar, deberá revisar la sintaxis de los archivos de configuración con el argumento -t de la línea de comandos (ver Arrancando Apache). Ésto aún no garantiza que el servidor pueda reiniciar correctamente. Para revisar la semántica de los archivos de configuración como también su sintaxis, deberá probar arrancar httpd como un usuario normal (no root) De no existir errores, intentará abrir los sockets y los archivos log y fallar porque no está arrancando como root (o porque hay actualmente un httpd corriendo y usando esos puertos). Si falla por cualquier otro motivo entonces probablemente hay un error en la configuración y dicho error deberá ser reparado antes de ejecutar el rearranque agraciado.

Apéndice: señales y condiciones de carrera

Previo a la versión de Apache 1.2b9 había condiciones de carrera que involucran el rearranque y las señales de muerte (una descripción simple de condición de carrera es: un problema sensitivo al tiempo, como por ejemplo, si algo ocurre en un mal momento que no se comportará como se esperaba). Para aquellas arquitecturas que tienen "correcto" el set de características, hemos eliminado tantas como pudimos. Pero debe ser notado que aún existen condiciones de carrera sobre algunas arquitecturas.

Arquitecturas que usan el ScoreBoardFile en disco, tienen el potencial de corromper sus marcadores. Ésto puede resultar en un error "bind: dirección ya está en uso" (después de HUP) o "long lost child came home! (¡el hijo, perdido hace mucho tiempo, ha retornado a la casa!" (después de USR1). El anterior es un error fatal, mientras que el último solo causa que el servidor pierda un slot del scoreboard. Entonces es aconsajable usar reinicio agraciado, con algún reinicio duro ocasional. Estos problemas son muy difíciles de solucionar, pero afortunadamente la mayoría de las arquitecturas no requieren un archivo de marcador (scoreboard). Vea la documentación de ScoreBoardFile para determinar si su arquitectura lo usa.

NEXT y MACHTEN (solo para 68k) tienen una pequeña condición de carrera, la cual puede causar que las señales de reinicio/muerte se pierdan, pero no deberían causar nada problemático al servidor.

Todas las arquitecturas tienen una pequeña condición de carrera en cada hijo involucrando al segundo y subsiguientes requerimientos sobre una conexión HTTP persistente (KeepAlive). Éste puede terminar luego de leer la línea requerida pero antes de leer cualquiera de los encabezados requeridos. Una solución fue descubierta demasiado tarde para la versión 1.2. En teoría, ésto no es un problema porque el cliente KeepAlive tiene que esperar estos eventos por los tiempos de latencia de la red y los tiempos de espera del servidor. En la práctica no parece afectar nada --en un test, el servidor fue reiniciado veinte veces por segundo y los clientes han navegado exitosamente el sitio web sin obtener imágenes truncadas o documentos vacíos.


Servidor HTTP Apache

Índice