Las directivas AcceptMutex determinan el método que usa Apache para serializar múltiples procesos hijo que aceptan peticiones en las conexiones de red. En las versiones de Apache anteriores a la 2.0, el método era seleccionable solo cuando se compilaba el servidor. El mejor método a usar depende mucho de la arquitectura y de la plataforma que use. Si desea más información, consulte la documentanción sobre ajustes para conseguir un mejor rendimiento.

Si el valor especificado en esta directiva es Default, entonces se usará el método seleccionado cuando se compiló el servidor. Más abajo puede encontrar una lista con otros métodos. Tenga en cuenta que no todos los métodos están disponibles en todas las plataformas. Si el método especificado no está disponible, se escribirá un mensaje en el log de errores con una lista de los métodos que puede usar.

flock

usa la llamada al sistema flock(2) para bloquear el fichero especificado en la directiva LockFile.

fcntl

usa la llamada al sistema fcntl(2) para bloquear el fichero especificado en la directiva LockFile.

posixsem

usa semáforos compatibles con POSIX para implementar el mutex.

pthread

Usa mutexes POSIX implementados según la especificación de hebras POSIX (PThreads).

sysvsem

usa semáforos de tipo SySV para implementar el mutex.

Si quiere ver cuál es el método por defecto que se seleccionó para usar en su sistema al compilar, especifique el valor debug en la directiva LogLevel. El valor por defecto de la directiva AcceptMutex aparecerá escrito en el ErrorLog.

La directiva BS2000Account está disponible solo en hosts BS2000. Debe usarse para definir el número de cuenta del usuario sin privilegios del servidor Apache (que se configuró usando la directiva User). Esto es un requerimiento del subsistema POSIX BS2000 (@@@@@ para reemplazar el entorno de tareas BS2000 subyaciente haciendo un sub-LOGON) para prevenir que scripts CGI accedan a recursos de la cuenta con privilegios con la que se suele iniciar el servidor, normalmente SYSROOT.

Esta directiva controla el directorio al cual intenta cambiarse Apache antes de realizar un volcado de memoria. Por defecto, el volcado de memoria se hace en el directorio especificado en la directiva ServerRoot, sin embargo, como el usuario con el que se está ejecutando Apache podría no tener permisos para escribir en ese directorio, los volcados de memoria muchas veces no se hacen en ningún sitio. Si quiere que el volcado se memoria se guarde para analizar los fallos posteriormente, puede usar esta directiva para especificar un directorio diferente.

Por razones de seguridad esta directiva está disponible solamente si el servidor ha sido configurado con la opción --enable-exception-hook. Esto activa un hook que permite que se conecten módulos externos y que realicen alguna acción después de que un proceso hijo sufra un error irrecuperable.

Hay otros dos módulos, mod_whatkilledus y mod_backtrace que usan este hook. Por favor, consulte el siguiente enlace, EnableExceptionHook perteneciente al sitio web de Jeff Trawick para obtener más información sobre el tema.

La directiva Group determina el grupo con el que el servidor atenderá las peticiones. Para usar esta directiva, el servidor debe haber sido iniciado con el usuario root. Si inicia el servidor con un usuario que no sea root, el servidor no podrá cambiarse al grupo especificado, en lugar de esto continuará ejecutándose con el grupo del usuario que lo inició. Unix-group debe tomar un de los siguiente valores:

El nombre de un grupo

Se refiere al grupo que lleva el nombre que se especifica.

# seguido del número de un grupo.

Se refiere al grupo asociado a ese número.

Se recomienda que cree un nuevo grupo específicamente para ejecutar el servidor. Algunos administradores usan el ususario nobody, pero esto no es siempre posible ni aconsejable.

Importante: El uso de esta directiva en VirtualHost no está permitido ya. Para configurar su servidor para suexec use la directiva SuexecUserGroup.

La directiva PidFile especifica el fichero en el que el servidor guarda el ID del proceso demonio de escucha (daemon). Si el nombre del fichero especificado no es una ruta absoluta, entonces se asume que es relativa al directorio especificado en ServerRoot.

Con frecuencia es útil tener la posibilidad de enviar al servidor una señal, de manera que cierre y vuelva a abrir el ErrorLog y el TransferLog, y vuelva a leer los ficheros de configuración. Esto es lo que ocurre cuando se envía la señal SIGHUP (kill -1) al ID del proceso que aparece en PidFile.

El PidFile está sujeto a las mismas advertencias que se hicieron para los ficheros log sobre su ubicación y sobre su seguridad.

La directiva Listen indica las direcciones IP y los puertos en los que debe escuchar Apache; por defecto, el servidor responde a las peticiones que se reciban en cualquier dirección IP de las interfaces de red. El uso de Listen es ahora obligatorio. Si no está en el fichero de configuración, el servidor no podrá iniciarse. Esto supone un cambio respecto a las versiones anteriores de Apache.

La directiva Listen le especifica al servidor los puertos o las combinaciones de direcciones y puertos cuyas peticiones debe aceptar. Si solamente se especifica un número de puerto, el servidor escuchará en ese puerto, en todas las interfaces de red. Si se especifica una dirección IP y un puerto, el servidor escuchará solamente en esa dirección IP y en ese puerto.

Se pueden usar varias directivas Listen para especificar varias direcciones y puertos de escucha. El servidor responderá a peticiones de cualquiera de esas direcciones y puertos.

Por ejemplo, para hacer que el servidor acepte conexiones en los puertos 80 y 8000, use:

Para hacer que el servidor acepte conexiones en dos direcciones y puertos difrentes, use

Las direcciones IPv6 deben escribirse entre corchetes, como en el siguiente ejemplo:

Longitud máxima de la cola de conexiones en espera. En general, no es necesario ni deseable hacer ninguna modificación, pero en algunos sistemas es beneficioso incrementar esta longitud cuando se está sufriendo un ataque TCP SYN flood. Consulte la información sobre el parámetro backlog de la llamada al sistema listen(2).

Este número estará la mayor parte de las veces limitado a un valor aún menor por el sistema operativo. Esto varía de un sistema operativo a otro. Tenga en cuenta también que muchos sistemas operativos no usan exactamente lo que se especifica en el backlog, sino que usan un número basado en el valor especificado (aunque normalmente mayor).

La directiva LockFile especifica la ruta al archivo de lock (lockfile) que se utiliza cuando la directiva AcceptMutex tiene valor fcntl o flock. En principio no se debe modificar el valor por defecto de esta directiva. La razón principal para moficiarlo es que el directorio de logs esté montado en NFS, porque el archivo de lock debe almacenarse en un disco local. El PID del proceso principal del servidor se añade automáticamente al nombre del fichero.

La directiva MaxClients especifica el límite de peticiones simultáneas que serán atendidas. Cualquier intento de conexión por encima del límite MaxClients se pondrá en cola, hasta llegar a un límite basado en el valor de la directiva ListenBacklog. Una vez que un proceso hijo termina de atender una petición y queda libre, se atenderá una conexión en cola.

En servidores que no usan hebras (por ejemplo, prefork), el valor especificado en MaxClients se traduce en el número máximo de procesos hijo que se crearán para atender peticiones. El valor por defecto es 256; para incrementarlo, debe incrementar también el valor especificado en la directiva ServerLimit.

En servidores que usan hebras y en servidores híbridos (por ejemplo, beos o worker) MaxClients limita el número total de hebras que van a estar disponibles para servir clientes. El valor por defecto para beos es 50. Para MPMs híbridos el valor por defecto es 16 (ServerLimit) multiplicado por 25 (ThreadsPerChild). Por lo tanto, si va a usar en MaxClients un valor que requiera más de 16 procesos deberá también incrementar el valor de la directiva ServerLimit.

La directiva MaxMemFree especifica el número máximo de kbytes libres que el asignador de memoria principal puede tomar sin hacer una llamada al sistema free(). Cuando no se especifica ningún valor en esta directiva, o cuando se especifica el valor cero, no existirá tal límite.

La directiva MaxRequestsPerChild especifica el número máximo de peticiones que un proceso hijo atenderá durante su existencia. Después de atender MaxRequestsPerChild peticiones, el proceso hijo se eliminará. Si el valor especificado en esta directiva MaxRequestsPerChild es 0, no habrá límite.

Especificar en la directiva MaxRequestsPerChild un valor distinto de cero tiene dos ventajas:

• limita la cantidad de memoria que un proceso puede consumir en caso de que haya un fuga (accidental) de memoria;
• establece un límite finito a la vida de los procesos, lo que ayuda a reducir el número existente de procesos cuando se reduce la carga de trabajo en el servidor.

Número máximo de hebras en espera. Los diferentes MPMs tienen diferentes comportamientos respecto a esta directiva.

En el módulo perchild el valor por defecto usado es MaxSpareThreads 10. Este MPM monitoriza el número de hebras en espera por proceso hijo. Si hay demasiadas hebras en espera en un proceso hijo, el servidor empezará a eliminar las hebras de sobra.

En los módulos worker, leader y threadpool el valor por defecto usado es MaxSpareThreads 250. Estos MPMs monitorizan el número del hebras en espera en servidor en conjunto. Si hay demasiadas hebras en espera en el servidor, se eliminan algunos procesos hijo hasta que el número de hebras en espera se ajuste al límite especificado.

En el módulo mpm_netware el valor por defecto usado es MaxSpareThreads 100. Como este MPM ejecuta único proceso, las hebras en espera se calculan también en base al servidor en conjunto.

Los módulos beos y mpmt_os2 funcionan de manera similar a mpm_netware. El valor por defecto para beos es MaxSpareThreads 50. Para mpmt_os2 el valor por defecto es 10.

Número mínimo de hebras en espera para atender picos de demanda en las peticiones. Los diferentes MPMs tratan esta directiva de forma diferente.

El módulo perchild usa por defecto MinSpareThreads 5 y calcula el número de hebras en espera en base al número de procesos hijo. Si no hay suficientes hebras en espera en un proceso hijo, el servidor empezará a crear nuevas hebras dentro de ese proceso hijo. De esta manera, si especifica en la directiva NumServers el valor 10 y en la directiva MinSpareThreads un valor de 5, tendrá como mínimo 50 hebras en espera en su sistema.

Los módulos worker, leader y threadpool usan un valor por defecto MinSpareThreads 75 y calculan el número de hebras en espera en el servidor en conjunto. Si no hay suficientes hebras en espera en el servidor, entonces se crean procesos hijo hasta que el número de hebras en espera sea suficiente.

El módulo mpm_netware usa un valor por defecto MinSpareThreads 10 y como es un MPM que trabaja con un único proceso, calcula el número de hebras en espera en base al número total que hay en el servidor.

Los módulos beos y mpmt_os2 funcionan de modo similar a como lo hace el módulo mpm_netware. El valor por defecto que usa beos es MinSpareThreads 1. mpmt_os2 usa por defecto el valor 5.

Apache usa un marcador para que los procesos hijo se comuniquen con sus procesos padre. Algunas arquitecturas necesitan un archivo para facilitar esta comunicación. Si no se especifica ningún fichero, Apache intenta en primer lugar crear el marcador en memoria (usando memoria compartida anónima) y, si esto falla, intentará crear el fichero en disco (usando memoria compartida basada en ficheros). Si se especifica un valor en esta directiva, Apache creará directamente el archivo en disco.

El uso de memoria compartida basada en ficheros es útil para aplicaciones de terceras partes que necesitan acceso directo al marcador.

Si usa la directiva ScoreBoardFile, puede mejorar la velocidad del servidor poniendo el fichero en memoria RAM. Pero tenga cuidado y siga las mismas recomendaciones acerca del lugar donde se almacenan los ficheros log y su seguridad.

El servidor fijará el tamaño del buffer TCP en los bytes que se especifiquen en esta directiva. Incrementar este valor por encima de los valores estándar del sistema operativo es muy útil en situaciones de alta velocidad y gran latencia (por ejemplo, 100ms o así, como en el caso de conexiones intercontinentales de gran capacidad).

Si se especifica el valor 0, el servidor usará el valor por defecto del sistema operativo.

En el módulo MPM prefork, esta directiva significa el valor máximo que se puede especificar en la directiva MaxClients sobre el tiempo de vida de un proceso de Apache. En el módulo MPM worker, esta diretiva en combinación con la directiva ThreadLimit significa el valor máximo que puede especificarse en la directiva MaxClients sobre el tiempo de vida de un proceso de Apache. Los intententos de cambiar el valor de esta directiva durante el reinicio del servidor serán ignorados. El valor de MaxClients sí que puede modificarse durante el reinicio.

Cuando se usa esta directiva hay que tener especial cuidado. Si en la directiva ServerLimit se especifica un valor mucho más alto de lo necesario, se reservará memoria compartida que no será usada. Si ambas directivas ServerLimit y MaxClients tienen especificados valores mayores que los que el sistema puede manejar, Apache puede que no se inicie o que el sistema se vuelva inestable.

Con el módulo MPM prefork, use esta directiva solamente si necesita especificar en la directiva MaxClients un valor mayor a 256 (el valor por defecto). No especifique un valor mayor del que vaya a especificar en la directiva MaxClients.

Con los módulos worker, leader y threadpool use esta directiva solamente si los valores especificados en las directivas MaxClients y ThreadsPerChild precisan más de 16 procesos del servidor (valor por defecto). No especifique en esta directiva un valor mayor que el número de procesos del servidor requeridos por lo especificado en las directivas MaxClients y ThreadsPerChild.

Con el MPM perchild, use esta directiva solo si tiene que especificar en la directiva NumServers un valor mayor de 8 (el valor por defecto).

La directiva StartServers especifica el número de procesos hijo que se crean al iniciar Apache. Como el número de procesos está controlado dinámicamente según la carga del servidor, no hay normalmente ninguna razón para modificar el valor de este parámetro.

El valor por defecto cambia según el MPM de que se trate. Para leader, threadpool y worker el valor por defecto es StartServers 3. Para prefork el valor por defecto es 5 y para mpmt_os2 es 2.

Número de hebras que se crean al iniciar Apache. Como el número de procesos está controlado dinámicamente según la carga del servidor, no hay normalmente ninguna razón para modificar el valor de este parámetro.

En el módulo perchild el valor por defecto es StartThreads 5 y esta directiva controla el número de hebras por proceso al inicio.

En el módulo mpm_netware el valor por defecto es StartThreads 50 y, como solamente hay un proceso, este es el número total de hebras creadas al iniciar el servidor para servir peticiones.

En el módulo beos el valor usado por defecto es StartThreads 10. En este caso también representa el número total de hebras creadas al iniciar el servidor para servir peticiones.

Esta directiva determina el valor máximo que puede especificarse en la directiva ThreadsPerChild para el tiempo de vida de un proceso de Apache. Los intentos por modificar este valor durante un reinicio serán ingnorados, pero el valor de la directiva ThreadsPerChild puede modificarse durante un reinicio hasta un valor igual al de esta directiva.

Cuando se usa esta directiva hay que poner especial atención. Si en la directiva ThreadLimit se especifica un valor mucho más grande que en ThreadsPerChild, se reservará memoria compartida en exceso que no será usada. Si tanto en ThreadLimit como en ThreadsPerChild se especifican valores mayores de los que el sistema puede tratar, Apache podría no iniciarse o su funcionamiento podría volverse inestable. No especifique en esta directiva un valor mayor del mayor valor posible que piense que va a especificar en ThreadsPerChild para la ejecución de Apache de ese momento.

El valor por defecto de la directiva ThreadLimit es 1920 cuando se usa con mpm_winnt y 64 en otro caso.

Esta directiva especifica el número de hebras creadas por cada proceso hijo. El proceso hijo crea estas hebras al inicio y no vuelve a crear más. Si se usa un MPM como mpm_winnt, en el que solamente hay un proceso hijo, este número debería ser lo suficientemente grande como para atender toda la carga del servidor. Si se usa un módulo MPM como worker, en el que hay múltiples procesos hijo, el número total de hebras debería ser lo suficientemente grande como para atender la carga en circustancias normales del servidor.

El valor por defecto de la directiva ThreadsPerChild es 64 cuando se usa mpm_winnt y 25 en otro caso.

La directiva User especifica el identificador de usuario con el que el servidor responderá a las peticiones. Para usar esta directiva, el servidor debe haber sido iniciado como root. Si se inicia Apache con un usario distinto de root, no se podrá cambiar a un usuario con menores privilegios, y el servidor continuará ejecutándose con el usuario original. Si inicia el servidor como root, entonces es normal que el procedimiento padre siga ejecutándose como root. Unix-userid puede tomar uno de los siguientes valores:

Un nombre de ususario

Se refiere al usuario dado por su nombre.

# seguido por un número de usuario.

Se refiere al usuario que corresponde a ese número.

El usuario debe no tener privilegios suficientes para acceder a ficheros que no deban ser visibles para el mundo exterior, y de igual manera, el usuario no debe ser capaz de ejecutar código que no sea susceptible de ser objeto de respuestas a peticiones HTTP. Se recomienda que especifique un nuevo usuario y un nuevo grupo solamente para ejecutar el servidor. Algunos administradores usan el usuario nobody, pero esto no es siempre deseable, porque el usuario nobody puede tener otras funciones en su sistema.

Con el MPM perchild, que está diseñado para ejecutar hosts virtuales por diferentes ID de usuario, la directiva User define el ID de usuario para el servidor principal y para el resto de las secciones VirtualHost sin una directiva AssignUserID.

Nota especial: El uso de esta directiva en VirtualHost no está ya soportado. Para configurar su servidor para suexec use SuexecUserGroup.