Date: Wed, 8 Jun 2016 00:11:57 +0000 Subject: [PATCH] Translated to match english revision. Reviewed. build the html file git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1747328 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/stopping.html.es | 546 +++++++++++++++++----------------- docs/manual/stopping.xml.es | 250 ++++++++-------- docs/manual/stopping.xml.meta | 2 +- 3 files changed, 401 insertions(+), 397 deletions(-) diff --git a/docs/manual/stopping.html.es b/docs/manual/stopping.html.es index 14e20cc81b..7b0b2e6dd9 100644 --- a/docs/manual/stopping.html.es +++ b/docs/manual/stopping.html.es @@ -1,276 +1,278 @@ - - - - + + + + -Iniciar y Parar el servidor Apache - Servidor HTTP Apache Versión 2.5 - - - - - - - -

-Apache > Servidor HTTP > Documentación > Versión 2.5

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

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.

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

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.

+ --> +Iniciar y Parar el servidor Apache - Servidor HTTP Apache Versión 2.5 + + + + + + + +

+Apache > Servidor HTTP > Documentación > Versión 2.5

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.

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

Comentarios

+//--> \ No newline at end of file diff --git a/docs/manual/stopping.xml.es b/docs/manual/stopping.xml.es index da5aad17c2..48f5a364fe 100644 --- a/docs/manual/stopping.xml.es +++ b/docs/manual/stopping.xml.es @@ -1,7 +1,9 @@ - + + +