Iniciar y Parar el servidor Apache

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

Esta traducciÑn podrÌa estar obsoleta. Consulte la versiÑn en inglÈs de la documentaciÑn para comprobar si se han producido cambios recientemente.

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 Apache
Reinicio Graceful
Reiniciar Apache
ApÈndice: seßales y race conditions

Consulte tambiÈn

Comentarios

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 ejecutandose 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, HUP, y USR1, 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, 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 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 hijo inmediatamente. Esto puede tardar algunos minutos. Una vez que hayan terminado todos los procesos hijo, terminarÀ el proceso padre. Cualquier peticiÑn en proceso terminarÀ inmediatanmente, y ninguna peticiÑn posterior serÀ atendida.

Reinicio Graceful

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 empeciezan a servir peticiones inmediatamente.

En algunas plataformas que no permiten usar USR1 para reinicios graceful, puede usarse una seßal alternativa (como WINCH). Tambien 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 y hebras 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 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, entoces 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 reinciciarÀ y terminarÀ con un error. En caso de un reinicio graceful, tambiÈn dejarÀ a los procesos hijo ejecutandose 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 configuracion 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 cebeceras de peticiÑn. Hay una soluciÑn que fue descubierta demasiado tarde para la incluirla en versiÑn 1.2. En teoria 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.