<-
Apache > Servidor HTTP > Documentaci�n > Versi�n 2.0

Iniciar y Parar el servidor Apache

Idiomas disponibles:  de  |  en  |  es  |  ja  |  ko  |  ru 

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.

Consulte tambi�n

top

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 c�mo 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.

top

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.

top

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.
top

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.
top

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.

Idiomas disponibles:  de  |  en  |  es  |  ja  |  ko  |  ru