Tengo dos servidores CentOS 5 con especificaciones casi idénticas. Cuando inicio sesión y lo hago ulimit -u
, en una máquina obtengo unlimited
, y en la otra obtengo 77824
.
Cuando ejecuto un cron como:
* * * * * ulimit -u > ulimit.txt
Obtengo los mismos resultados ( unlimited
, 77824
).
Estoy tratando de determinar dónde están configurados para poder alterarlos. Ellos no están escritas en cualquiera de mis perfiles ( .bashrc
, /etc/profile
, etc.). Estos no afectarían cron de todos modos) ni en /etc/security/limits.conf
(que está vacío).
He buscado en Google e incluso he ido tan lejos como para hacerlo grep -Ir 77824 /
, pero nada ha aparecido hasta ahora. No entiendo cómo estas máquinas podrían haber sido preestablecidas con límites diferentes.
De hecho, no me pregunto por estas máquinas, sino por una máquina diferente (CentOS 6) que tiene un límite de 1024
, que es demasiado pequeño. Necesito ejecutar trabajos cron con un límite más alto y la única forma en que sé cómo configurarlo es en el trabajo cron en sí. Está bien, pero prefiero configurarlo en todo el sistema para que no sea tan hacky.
Gracias por cualquier ayuda. Esto parece que debería ser fácil (NO).
EDITAR - RESUELTO
Ok, me di cuenta de esto. Parece ser un problema con CentOS 6 o quizás con la configuración de mi máquina. En la configuración de CentOS 5, puedo configurar /etc/security/limits.conf
:
* - nproc unlimited
y eso actualizaría efectivamente las cuentas y los límites cron. Sin embargo, esto no funciona en mi caja CentOS 6. En cambio, debo hacer:
myname1 - nproc unlimited
myname2 - nproc unlimited
...
Y las cosas funcionan como se esperaba. Tal vez la especificación UID funciona, pero el comodín (*) definitivamente NO lo hace aquí. Curiosamente, los comodines sí funcionan para el nofile
límite.
Todavía me gustaría saber de dónde provienen los valores predeterminados, porque de manera predeterminada, este archivo está vacío y no pude ver por qué tenía diferentes valores predeterminados para las dos cajas CentOS, que tenían hardware idéntico y eran del mismo proveedor .
/etc/security/limits.d/
?Respuestas:
Estos límites "predeterminados" se aplican mediante:
init
proceso),fork(2)
momento),setrlimit(2)
).Los procesos normales de los usuarios no pueden aumentar los límites duros.
El kernel de Linux
En el momento del arranque, Linux establece límites predeterminados para el
init
proceso, que luego son heredados por todos los demás procesos (secundarios). Para ver estos límites:cat /proc/1/limits
.Por ejemplo, el valor predeterminado del núcleo para el número máximo de descriptores de archivo (
ulimit -n
) era 1024/1024 (suave, duro) y se ha elevado a 1024/4096 en Linux 2.6.39.El número máximo predeterminado de procesos del que está hablando se limita a aproximadamente:
para arquitecturas x86 (por lo menos), pero a veces las distribuciones cambiar los valores predeterminados del núcleo, por lo que comprobar su código fuente del kernel para
kernel/fork.c
,fork_init()
. El límite de "número de procesos" se llama RLIMIT_NPROC allí.PAM
Por lo general, para garantizar la autenticación del usuario al iniciar sesión, se usa PAM junto con algunos módulos (ver
/etc/pam.d/login
).En Debian, el módulo PAM responsable de establecer límites está aquí:
/lib/security/pam_limits.so
.Esta biblioteca leerá su configuración desde
/etc/security/limits.conf
y/etc/security/limits.d/*.conf
, pero incluso si esos archivos están vacíos, pam_limits.so podría usar valores codificados que puede verificar dentro del código fuente.Por ejemplo, en Debian, la biblioteca ha sido parcheada de manera que, por defecto, el número máximo de procesos (
nproc
) es ilimitado y el número máximo de archivos (nofile
) es 1024/1024:Por lo tanto, verifique el código fuente del módulo PAM de CentOS (busque RLIMIT_NPROC).
Sin embargo, tenga en cuenta que muchos procesos no pasarán por PAM (generalmente, si no son iniciados por un usuario conectado, como demonios y tal vez trabajos cron).
fuente
/etc/initscript
: "un lugar conveniente para ajustar por límites de proceso", configurable a través de/etc/sysconfig/ulimit
./proc/1/limits
) desde la versión 1.1.4 (lanzada en 2011).En RHEL6 (CentOS6) "procesos de usuario máximos" se establece en 1024 de forma predeterminada.
Puede cambiar este valor en el archivo:
Consulte https://bugzilla.redhat.com/show_bug.cgi?id=432903 si desea quejarse al respecto :)
fuente
Cuando revisó los límites, ¿estaba usando el usuario root para hacerlo?
Desde la página del
limits.conf
manual:El uso de nombres de usuario explícitos resolvería el problema en este caso.
fuente
limits.conf
archivo está vacío (como ellimits.d
directorio).La información sobre esto es terrible en Internet, heres un archivo limit.conf que hice para Debian Linux, que muestra todas las opciones posibles y sus límites máximos "seguros", ajustar en consecuencia.
Estos son los valores más altos que puede establecer, algunas cosas se descifran, la activación de esas causas hace que salga por error y no pueda iniciar sesión en su consola, modifique las opciones comentadas bajo su propio riesgo, pero no debería necesitarlo (el valor predeterminado es ilimitado en la mayoría)
Espero que esto sea útil para alguien, ya que no pude encontrar esta información en ninguna parte, hay 4 horas de investigación en este archivo.
fuente
kernel / fork.c
En 64 bits, el tamaño de la rosca es 8192
Ahora obtengo el total en kb en división por 4
Ahora tengo el número de páginas.
El resultado final es
De esta manera, obtuvo el parámetro thread-max y el límite predeterminado del proceso del usuario es la mitad
ulimit desde la raíz
fuente
Parece ser /etc/security/limits.conf
http://ss64.com/bash/limits.conf.html
fuente
Hay una posibilidad más de que la configuración de "noproc" no funcione mientras se configura en /etc/security/limits.conf.
Hay un archivo más que anula su configuración /etc/security/limits.d/90-nproc.conf.
Aquí * config anulará lo que haya establecido en el archivo de configuración anterior. Lo ideal es que configure su configuración en este archivo.
fuente