Gestión de Límites de Recursos en Linux con /etc/security/limits.conf

En sistemas Linux, cada proceso consume recursos del sistema como CPU, memoria, descriptores de archivo, espacio en disco, entre otros. Para evitar abusos, fallos de software o ataques que comprometan la estabilidad del sistema, es posible establecer límites de recursos por usuario o grupo.

Uno de los mecanismos más utilizados para este control es el archivo /etc/security/limits.conf, parte del sistema PAM (Pluggable Authentication Modules) mediante el módulo pam_limits.so. Este archivo permite definir reglas de uso de recursos de manera granular y flexible.

Ubicación y relación con PAM

• Archivo principal: /etc/security/limits.conf
• Configuraciones adicionales: /etc/security/limits.d/*.conf
• Módulo relacionado: pam_limits.so
• Archivos de PAM donde se suele cargar:
  • Debian/Ubuntu: /etc/pam.d/common-session, /etc/pam.d/common-session-noninteractive
  • CentOS/RHEL: /etc/pam.d/system-auth

Si el módulo pam_limits.so no está cargado, los límites definidos en limits.conf no se aplicarán.

Sintaxis de limits.conf

Cada regla en el archivo sigue la siguiente estructura:

<dominio>    <tipo>    <item>    <valor>

Elementos:

• <dominio>:
  • Usuario (juan)
  • Grupo (@developers)
  • Todos los usuarios (*)
• <tipo>:
  • soft: límite blando (aplicado por defecto).
  • hard: límite duro (máximo absoluto, no puede ser superado).
• <item>: recurso a limitar (ejemplos más abajo).
• <valor>: número entero o la palabra clave unlimited.

Recursos más comunes (<item>)

Algunos de los más utilizados son:

• nofile → número máximo de descriptores de archivo abiertos.
• nproc → número máximo de procesos por usuario.
• core → tamaño máximo de core dumps.
• cpu → tiempo máximo de CPU en minutos.
• data → tamaño máximo del segmento de datos.
• fsize → tamaño máximo de un archivo creado.
• as → espacio máximo de direcciones (memoria virtual).
• memlock → memoria bloqueada en RAM.
• stack → tamaño máximo de la pila de procesos.

Ejemplos prácticos

1. Limitar procesos de un usuario

Evitar que el usuario juan lance más de 100 procesos:

juan    soft    nproc    80
juan    hard    nproc    100

2. Limitar el tamaño máximo de archivos creados

Aplicable a todos los usuarios:

*    hard    fsize    1048576

3. Incrementar el número de ficheros abiertos para un grupo

Permitir que el grupo developers abra hasta 8192 archivos:

@developers    soft    nofile    4096
@developers    hard    nofile    8192

4. Configurar memoria ilimitada para Oracle

oracle    hard    as    unlimited

Caso específico: nofile

El parámetro nofile regula el número de descriptores de archivos que un proceso puede abrir.
Esto incluye:

• Archivos en disco.
• Sockets de red.
• Tuberías (pipes).

Por defecto, Linux suele poner valores conservadores como 1024 o 4096, lo cual es insuficiente para servidores de bases de datos o proxies de alto rendimiento.

Ejemplo de límites muy altos

*    soft    nofile    1048576
*    hard    nofile    1048576

📌 Con esta configuración:

• Todos los usuarios pueden abrir hasta 1.048.576 ficheros por proceso.
• Tanto el límite blando como el duro son iguales.

Se puede comprobar con:

ulimit -n       # Límite blando
ulimit -n -H    # Límite duro

Deslimitar un recurso

Si se desea eliminar los límites, se puede usar la palabra clave unlimited.

Ejemplo:

*    soft    nofile    unlimited
*    hard    nofile    unlimited

Esto implica que no existe límite en el número de descriptores de archivo abiertos por proceso.

Consideraciones importantes

1. Diferencia entre soft y hard

• El usuario arranca con el límite soft.
• Puede incrementarlo hasta el hard limit con ulimit -n <valor>.
• Nunca puede superar el hard.

2. Impacto de valores altos o ilimitados

• Cada descriptor de archivo ocupa memoria en el kernel (~ cientos de bytes).
• Valores excesivos o unlimited pueden agotar recursos del sistema si un proceso abre miles o millones de ficheros.
• Puede provocar caídas del sistema.

3. Integración con systemd

En sistemas modernos, systemd puede anular los valores de limits.conf.

• Configuración global: /etc/systemd/system.conf, /etc/systemd/user.conf
• Parámetro: DefaultLimitNOFILE=65535
• Configuración por servicio: /etc/systemd/system/<servicio>.service con la directiva: LimitNOFILE=65535

Si un servicio como nginx o mysql no refleja los límites configurados en limits.conf, probablemente haya que ajustarlos en su unidad de systemd.

Verificación

Para comprobar si los límites se aplicaron correctamente:

Sesión de usuario

ulimit -a     # muestra todos los límites activos

Servicio gestionado por systemd

systemctl show <servicio> | grep NOFILE

Proceso en ejecución

cat /proc/<PID>/limits

Buenas prácticas

1. No usar * para todos los usuarios cuando se trate de valores muy altos o unlimited.
   • Mejor aplicarlos solo a usuarios o grupos específicos.
2. Ajustar según la carga real del servicio.
   • Ejemplo: un servidor web de alto tráfico puede necesitar 65535 ficheros abiertos, pero rara vez 1 millón.
3. Coordinar con systemd.
   • De nada sirve modificar limits.conf si el servicio está controlado por systemd y tiene un límite propio inferior.
4. Revisar logs del kernel (dmesg) si un proceso se ve limitado inesperadamente.

Conclusión

El archivo /etc/security/limits.conf es una herramienta fundamental para administrar los recursos que los usuarios y procesos pueden consumir en un sistema Linux. Bien configurado, ayuda a proteger la estabilidad del sistema y a garantizar el correcto funcionamiento de servicios críticos.

Sin embargo, un mal uso —como establecer límites excesivamente altos o deslimitar recursos para todos los usuarios— puede tener el efecto contrario y comprometer la seguridad y disponibilidad del sistema.

La clave está en definir límites adecuados según las necesidades del servicio, verificar su aplicación con ulimit y, en entornos modernos, asegurarse de que systemd no anule la configuración.