| <?xml version='1.0' encoding='UTF-8' ?> |
| <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd"> |
| <?xml-stylesheet type="text/xsl" href="./style/manual.es.xsl"?> |
| <!-- English Revision: 105989:1174747 (outdated) --> |
| |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <manualpage metafile="stopping.xml.meta"> |
| |
| <title>Iniciar y Parar el servidor Apache</title> |
| |
| <summary> |
| <p>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 <a |
| href="platform/windows.html#winsvc">Ejecutar Apache como un |
| servicio</a> y los usuario de Windows 9x y ME deben consultar <a |
| href="platform/windows.html#wincons">Ejecutar Apache como una |
| Aplicación de Consola</a> para obtener información |
| sobre como controlar Apache en esas plataformas.</p> |
| </summary> |
| |
| <seealso><a href="programs/httpd.html">httpd</a></seealso> |
| <seealso><a href="programs/apachectl.html">apachectl</a></seealso> |
| |
| <section id="introduction"><title>Introducción</title> |
| |
| <p>Para parar y reiniciar Apache, hay que enviar la señal |
| apropiada al proceso padre <code>httpd</code> que se esté |
| ejecutando. Hay dos maneras de enviar estas señales. En |
| primer lugar, puede usar el comando de Unix <code>kill</code> que |
| envía señales directamente a los procesos. Puede que |
| tenga varios procesos <code>httpd</code> ejecutandose en su |
| sistema, pero las señales deben enviarse solamente al proceso |
| padre, cuyo pid está especificado en la directiva <directive |
| module="mpm_common">PidFile</directive>. 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: <code><a href="#term">TERM</a></code>, <code><a |
| href="#hup">HUP</a></code>, y <code><a |
| href="#graceful">USR1</a></code>, que van a ser descritas a |
| continuación.</p> |
| |
| <p>Para enviar una señal al proceso padre debe escribir un |
| comando como el que se muestra en el ejemplo:</p> |
| |
| <example>kill -TERM `cat /usr/local/apache2/logs/httpd.pid`</example> |
| |
| <p>La segunda manera de enviar señales a los procesos |
| <code>httpd</code> es usando las opciones de línea de |
| comandos <code>-k</code>: <code>stop</code>, <code>restart</code>, |
| y <code>graceful</code>, como se muestra más abajo. Estas |
| opciones se le pueden pasar al binario <a |
| href="programs/httpd.html">httpd</a>, pero se recomienda que se |
| pasen al script de control <a |
| href="programs/apachectl.html">apachectl</a>, que a su vez los |
| pasará a <code>httpd</code>.</p> |
| |
| <p>Después de haber enviado las señales que desee a |
| <code>httpd</code>, puede ver como progresa el proceso |
| escribiendo:</p> |
| |
| <example>tail -f /usr/local/apache2/logs/error_log</example> |
| |
| <p>Modifique estos ejemplos para que coincidan con la |
| configuración que tenga especificada en las directivas |
| <directive module="core">ServerRoot</directive> y <directive |
| module="mpm_common">PidFile</directive> en su fichero principal de |
| configuración.</p> |
| </section> |
| |
| <section id="term"><title>Parar Apache</title> |
| |
| <dl><dt>Señal: TERM</dt> |
| <dd><code>apachectl -k stop</code></dd> |
| </dl> |
| |
| <p>Enviar las señales <code>TERM</code> o <code>stop</code> |
| 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.</p> |
| </section> |
| |
| <section id="graceful"><title>Reinicio Graceful</title> |
| |
| <dl><dt>Señal: USR1</dt> |
| <dd><code>apachectl -k graceful</code></dd> |
| </dl> |
| |
| <p>Las señales <code>USR1</code> o <code>graceful</code> |
| hacen que el proceso padre <em>indique</em> 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 <em>generación</em> con |
| la nueva configuración, que empeciezan a servir peticiones |
| inmediatamente.</p> |
| |
| <note>En algunas plataformas que no permiten usar |
| <code>USR1</code> para reinicios graceful, puede usarse una |
| señal alternativa (como <code>WINCH</code>). Tambien puede |
| usar <code>apachectl graceful</code> y el script de control |
| enviará la señal adecuada para su plataforma.</note> |
| |
| <p>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 <directive |
| module="mpm_common">StartServers</directive> de la siguiente |
| manera: si después de al menos un segundo el nuevo hijo de la |
| directiva <directive module="mpm_common">StartServers</directive> |
| 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 |
| <directive>StartServers</directive>.</p> |
| |
| <p>Los usuarios del módulo <module>mod_status</module> |
| notarán que las estadísticas del servidor |
| <strong>no</strong> se ponen a cero cuando se usa la señal |
| <code>USR1</code>. 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 |
| <em>scoreboard</em> usado para llevar el registro de los procesos |
| hijo a través de las distintas generaciones.</p> |
| |
| <p>El mod_status también usa una <code>G</code> para indicar |
| que esos hijos están todavía sirviendo peticiones |
| previas al reinicio graceful.</p> |
| |
| <p>Actualmente no existe ninguna manera de que un script con un |
| log de rotación usando <code>USR1</code> 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 <code>USR1</code> |
| 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.</p> |
| |
| <note>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 <code>-t</code> (consulte <a |
| href="programs/httpd.html">httpd</a>). 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 <code>httpd</code> 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 <code>httpd</code> 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.</note> |
| </section> |
| |
| <section id="hup"><title>Reiniciar Apache</title> |
| |
| <dl><dt>Señal: HUP</dt> |
| <dd><code>apachectl -k restart</code></dd> |
| </dl> |
| |
| <p>El envío de las señales <code>HUP</code> o |
| <code>restart</code> al proceso padre hace que los procesos hijo |
| terminen como si le enviá ramos la señal |
| <code>TERM</code>, 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.</p> |
| |
| <p>Los usuarios del módulo <module>mod_status</module> |
| notarán que las estadísticas del servidor se ponen a |
| cero cuando se envía la señal <code>HUP</code>.</p> |
| |
| <note>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.</note> |
| </section> |
| |
| <section id="race"><title>Apéndice: señales y race conditions</title> |
| |
| <p>Con anterioridad a la versión de Apache 1.2b9 había |
| varias <em>race conditions</em> 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.</p> |
| |
| <p>En las arquitecturas que usan un <directive |
| module="mpm_common">ScoreBoardFile</directive> 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 usar<code>HUP</code>) o el error "long lost child |
| came home!" (después de usar <code>USR1</code>). 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 |
| <directive module="mpm_common">ScoreBoardFile</directive> para ver |
| las arquitecturas que la usan.</p> |
| |
| <p>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. </p> |
| </section> |
| |
| </manualpage> |
| |