# Gestión de Límites de Recursos en Linux con /etc/security/limits.conf - Link: https://binariocero.com/linux/gestion-de-limites-de-recursos-en-linux-con-etc-security-limits-conf - Published: 2025-09-23T07:39:57+02:00 - Author: Juan José Fernández Durán ![Loading](https://binariocero.com/wp-content/plugins/page-views-count/ajax-loader- 2x.gif) 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: ```wp-block-code ``` ### Elementos: * **``**: - Usuario (`juan`) - Grupo (`@developers`) - Todos los usuarios (`*`) * **``**: - `soft`: límite blando (aplicado por defecto). - `hard`: límite duro (máximo absoluto, no puede ser superado). * **``**: recurso a limitar (ejemplos más abajo). * **``**: número entero o la palabra clave `unlimited`. ## Recursos más comunes (``) 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: ```wp-block-code juan soft nproc 80 juan hard nproc 100 ``` ### 2. Limitar el tamaño máximo de archivos creados Aplicable a todos los usuarios: ```wp-block-code * hard fsize 1048576 ``` ### 3. Incrementar el número de ficheros abiertos para un grupo Permitir que el grupo `developers` abra hasta 8192 archivos: ```wp-block-code @developers soft nofile 4096 @developers hard nofile 8192 ``` ### 4. Configurar memoria ilimitada para Oracle ```wp-block-code 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 ```wp-block-code * 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: ```wp-block-code 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: ```wp-block-code * 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 `. * 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/.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 ```wp-block-code ulimit -a # muestra todos los límites activos ``` ### Servicio gestionado por `systemd` ```wp-block-code systemctl show | grep NOFILE ``` ### Proceso en ejecución ```wp-block-code cat /proc//limits ``` ## Buenas prácticas 1. **No usar `\*` para todos los usuarios** cuando se trate de valores muy altos o` unlimited`. 2. * Mejor aplicarlos solo a usuarios o grupos específicos. 3. **Ajustar según la carga real del servicio**. 4. * Ejemplo: un servidor web de alto tráfico puede necesitar `65535` ficheros abiertos, pero rara vez `1 millón`. 5. **Coordinar con `systemd`**. 6. * De nada sirve modificar `limits.conf` si el servicio está controlado por `systemd` y tiene un límite propio inferior. 7. **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.