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`
tail -f /usr/local/apache/logs/error_log
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.
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.
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.
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.
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.