X-Git-Url: https://granicus.if.org/sourcecode?a=blobdiff_plain;f=docs%2Fmanual%2Fstopping.xml.es;h=48f5a364fed561a5b4960b3a0b0b5b7be3aa7159;hb=402ea113bbd93eef00e66ba0caaef75df15cd0e8;hp=c0d34e7dce43a0a2c30279303a86aecc19d24786;hpb=5f7fc8a0f85c822eb5be380bf850b7634395a287;p=apache

diff --git a/docs/manual/stopping.xml.es b/docs/manual/stopping.xml.es
index c0d34e7dce..48f5a364fe 100644
--- a/docs/manual/stopping.xml.es
+++ b/docs/manual/stopping.xml.es
@@ -1,15 +1,17 @@
 <?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:106803 (outdated) -->
+<!-- English Revision: 1174747 -->
+<!-- Translated by Luis Gil de Bernabé Pfeiffer lgilbernabe[AT]apache.org -->
+<!-- Reviewed by Sergio Ramos-->
 
 <!--
- Copyright 2004-2005 The Apache Software Foundation or its licensors,
-                     as applicable.
-
- Licensed 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
+ 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
 
@@ -27,237 +29,237 @@
 <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&#243;n <a
+     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&#243;n de Consola</a> para obtener informaci&#243;n
+     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>
+<seealso><program>httpd</program></seealso>
+<seealso><program>apachectl</program></seealso>
+<seealso><a href="invoking.html"></a>Iniciar Apache</seealso>
 
-<section id="introduction"><title>Introducci&#243;n</title>
+<section id="introduction"><title>Introducción</title>
 
-    <p>Para parar y reiniciar Apache, hay que enviar la se&#241;al
-    apropiada al proceso padre <code>httpd</code> que se est&#233;
-    ejecutando.  Hay dos maneras de enviar estas se&#241;ales.  En
+    <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&#237;a se&#241;ales directamente a los procesos. Puede que
-    tenga varios procesos <code>httpd</code> ejecutandose en su
-    sistema, pero las se&#241;ales deben enviarse solamente al proceso
-    padre, cuyo pid est&#225; especificado en la directiva <directive
+    envía señales directamente a los procesos. Puede que
+    tenga varios procesos <code>httpd</code> ejecutándose 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&#241;ales a ning&#250;n proceso excepto
-    al proceso padre. Hay tres se&#241;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&#243;n.</p>
-
-    <p>Para enviar una se&#241;al al proceso padre debe escribir un
+    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="#graceful">USR1</a></code>
+    <code><a href="#hup">HUP</a></code>, y
+    <code><a href="#gracefulstop">WINCH</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&#241;ales a los procesos
-    <code>httpd</code> es usando las opciones de l&#237;nea de
+    <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&#225;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&#225; a <code>httpd</code>.</p>
-
-    <p>Despu&#233;s de haber enviado las se&#241;ales que desee a
+    y <code>graceful</code> y <code>graceful-stop</code>, como se 
+    muestra más abajo. Estas opciones se le pueden pasar al binario 
+    <program>httpd</program>, pero se recomienda que se pasen al 
+    script de control <program>apachectl</program>, que a su vez los
+    pasará a <program>httpd</program>.</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&#243;n que tenga especificada en las directivas
+    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&#243;n.</p>
+    configuración.</p>
 </section>
 
-<section id="term"><title>Parar Apache</title>
+<section id="term"><title>Parar Ahora Apache</title>
 
-<dl><dt>Se&#241;al: TERM</dt>
+<dl><dt>Señal: TERM</dt>
 <dd><code>apachectl -k stop</code></dd>
 </dl>
 
-    <p>Enviar las se&#241;ales <code>TERM</code> o <code>stop</code>
+    <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&#225; el
-    proceso padre. Cualquier petici&#243;n en proceso terminar&#225;
-    inmediatanmente, y ninguna petici&#243;n posterior ser&#225;
+    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.</p>
 </section>
 
-<section id="graceful"><title>Reinicio Graceful</title>
+<section id="graceful"><title>Reinicio "Graceful" o elegante</title>
 
-<dl><dt>Se&#241;al: USR1</dt>
+<dl><dt>Señal: USR1</dt>
 <dd><code>apachectl -k graceful</code></dd>
 </dl>
 
-    <p>Las se&#241;ales <code>USR1</code> o <code>graceful</code>
+    <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&#233;s de servir la petici&#243;n que est&#233;n
-    atendiendo en ese momento (o de inmediato si no est&#225;n
-    sirviendo ninguna petici&#243;n). El proceso padre lee de nuevo
-    sus ficheros de configuraci&#243;n y vuelve a abrir sus ficheros
+    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&#243;n</em> con
-    la nueva configuraci&#243;n, que empeciezan a servir peticiones
+    sustituyendo con un hijo de una nueva <em>generación</em> con
+    la nueva configuración, que empiezan a servir peticiones
     inmediatamente.</p>
 
     <note>En algunas plataformas que no permiten usar
     <code>USR1</code> para reinicios graceful, puede usarse una
-    se&#241;al alternativa (como <code>WINCH</code>). Tambien puede
+    señal alternativa (como <code>WINCH</code>). También puede
     usar <code>apachectl graceful</code> y el script de control
-    enviar&#225; la se&#241;al adecuada para su plataforma.</note>
+    enviará la señal adecuada para su plataforma.</note>
 
-    <p>Apache est&#225; dise&#241;ado para respetar en todo momento la
-    directiva de control de procesos de los MPM, as&#237; como para
-    que el n&#250;mero de procesos y hebras disponibles para servir a
+    <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 e hilos disponibles para servir a
     los clientes se mantenga en los valores adecuados durante el
-    proceso de reinicio.  A&#250;n m&#225;s, est&#225; dise&#241;ado
+    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&#233;s de al menos un segundo el nuevo hijo de la
+    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&#237;, se intenta mantener
-    tanto el n&#250;mero de hijos adecuado para el trabajo que el
-    servidor tenga en ese momento, como respetar la configuraci&#243;n
-    determinada por los par&#225;metros de la directiva
+    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
     <directive>StartServers</directive>.</p>
 
-    <p>Los usuarios del m&#243;dulo <module>mod_status</module>
-    notar&#225;n que las estad&#237;sticas del servidor
-    <strong>no</strong> se ponen a cero cuando se usa la se&#241;al
+    <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&#225;n en cola por el sistema operativo, de modo que
-    se no se pierda ning&#250;n evento), como para respetar sus
-    par&#225;metros de ajuste. Para hacer esto, tiene que guardar el
+    (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&#233;s de las distintas generaciones.</p>
+    hijo a través de las distintas generaciones.</p>
 
-    <p>El mod_status tambi&#233;n usa una <code>G</code> para indicar
-    que esos hijos est&#225;n todav&#237;a sirviendo peticiones
+    <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&#243;n usando <code>USR1</code> sepa con seguridad
+    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&#233;s de enviar la se&#241;al <code>USR1</code>
+    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
+    baja velocidad tardan menos de 10 minutos en completarse, entonces
     espere 15 minutos antes de hacer nada con el log antiguo.</p>
 
-    <note>Si su fichero de configuraci&#243;n tiene errores cuando
-    haga el reinicio, entonces el proceso padre no se reinciciar&#225;
-    y terminar&#225; con un error. En caso de un reinicio graceful,
-    tambi&#233;n dejar&#225; a los procesos hijo ejecutandose mientras
-    existan.  (Estos son los hijos de los que se est&#225; saliendo de
-    forma graceful y que est&#225;n sirviendo sus &#250;ltimas
-    peticiones.) Esto provocar&#225; problemas si intenta reiniciar el
-    servidor -- no ser&#225; posible conectarse a la lista de puertos
+    <note>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 configuracion es correcta con la opci&#243;n de
-    l&#237;nea de comandos <code>-t</code> (consulte <a
-    href="programs/httpd.html">httpd</a>). No obstante, esto no
+    sus ficheros de configuración es correcta con la opción de
+    línea de comandos <code>-t</code> (consulte <program>httpd</program>). 
+    No obstante, esto no
     garantiza que el servidor se reinicie correctamente. Para
     comprobar que no hay errores en los ficheros de
-    configuraci&#243;n, puede intentar iniciar <code>httpd</code> con
-    un usuario diferente a root. Si no hay errores, intentar&#225;
-    abrir sus sockets y logs y fallar&#225; porque el usuario no es
-    root (o porque el <code>httpd</code> que se est&#225; ejecutando
-    en ese momento ya est&#225; conectado a esos puertos). Si falla
-    por cualquier otra raz&#243;n, entonces casi seguro que hay
-    alg&#250;n error en alguno de los ficheros de configuraci&#243;n y
+    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&#241;al: HUP</dt>
+<dl><dt>Señal: HUP</dt>
 <dd><code>apachectl -k restart</code></dd>
 </dl>
 
-    <p>El env&#237;o de las se&#241;ales <code>HUP</code> o
+    <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&#225; ramos la se&#241;al
+    terminen como si le enviáramos la señal
     <code>TERM</code>, para eliminar el proceso padre. La diferencia
-    est&#225; en que estas se&#241;ales vuelven a leer los archivos de
-    configuraci&#243;n y vuelven a abrir los ficheros log. Se genera
-    un nuevo conjunto de hijos y se contin&#250;a sirviendo
+    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&#243;dulo <module>mod_status</module>
-    notar&#225;n que las estad&#237;sticas del servidor se ponen a
-    cero cuando se env&#237;a la se&#241;al <code>HUP</code>.</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&#243;n contiene errores, cuando
+<note>Si su fichero de configuración contiene errores, cuando
 intente reiniciar, el proceso padre del servidor no se
-reiniciar&#225;, sino que terminar&#225; con un error. Consulte
-m&#225;s arriba c&#243;mo puede solucionar este problema.</note>
+reiniciará, sino que terminará con un error. Consulte
+más arriba cómo puede solucionar este problema.</note>
 </section>
 
-<section id="race"><title>Ap&#233;ndice: se&#241;ales y race conditions</title>
+<section id="race"><title>Apándice: señales y race conditions</title>
 
-    <p>Con anterioridad a la versi&#243;n de Apache 1.2b9 hab&#237;a
-    varias <em>race conditions</em> implicadas en las se&#241;ales
-    para parar y reiniciar procesos (una descripci&#243;n sencilla de
+    <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&#237;sticas "adecuadas", se han eliminado tantas race
+    características "adecuadas", se han eliminado tantas race
     conditions como ha sido posible. Pero hay que tener en cuenta que
-    todav&#237;a existen race conditions en algunas arquitecturas.</p>
+    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&#233;s de usar<code>HUP</code>) o el error "long lost child
-    came home!"  (despu&#233;s de usar <code>USR1</code>). En el
+    (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&#237;a aconsejable usar reinicios
+    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&#243;n de la directiva
+    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&#241;a race condition
+    <p>Todas las arquitecturas tienen una pequeña race condition
     en cada proceso hijo implicada en la segunda y subsiguientes
-    peticiones en una conexi&#243;n HTTP persistente
-    (KeepAlive). Puede ser que el servidor termine despu&#233;s de
-    leer la l&#237;nea de petici&#243;n pero antes de leer cualquiera
-    de las cebeceras de petici&#243;n. Hay una soluci&#243;n que fue
-    descubierta demasiado tarde para la incluirla en versi&#243;n
-    1.2. En teoria esto no debe suponer ning&#250;n problema porque el
+    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&#225;s
-    -- en una sesi&#243;n de pruebas, un servidor se reinici&#243;
+    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>
-