En el día a día de la administración de sistemas, a menudo nos movemos por inercia con comandos estándar. Sin embargo, cuando el rendimiento decae o un servicio se comporta de forma errática, necesitamos herramientas que nos permitan ver las entrañas del kernel. Hoy vamos a elevar el nivel analizando tres conceptos avanzados: la gestión multihilo, la activación por sockets en systemd y la auditoría total de descriptores de archivos.
1. Disección de Procesos: Cuando un PID no es suficiente
Todos conocemos ps aux, pero en entornos de bases de datos o servidores de aplicaciones pesados, ver el proceso padre es solo la punta del iceberg. Aplicaciones como MySQL/MariaDB, Java o Apache (con ciertos MPMs) generan múltiples hilos de ejecución (Threads) bajo un mismo proceso.
Si un servidor MySQL está consumiendo el 100% de la CPU, ¿es el proceso principal o un hilo específico atascado en una consulta compleja?
Para esto, el flag -L es nuestro mejor aliado.
# El comando correcto para filtrar procesos MySQL y ver sus hilos: ps -eLf | grep mysql
¿Qué estamos viendo aquí?
- LWP (Light Weight Process): En Linux, los hilos se manejan como procesos ligeros. Esta columna te muestra el ID único del hilo.
- NLWP (Number of Light Weight Processes): Te indica cuántos hilos tiene ese proceso en total.
Caso de uso SysAdmin: Si observas que el NLWP de un servicio crece descontroladamente, podrías estar ante un "thread leak" o una mala configuración en el pool de conexiones de tu base de datos.
2. Systemd y la magia de los Sockets (.socket)
En la vieja escuela (SysVinit), los demonios se iniciaban al arranque y se quedaban escuchando, consumiendo RAM aunque nadie los usara. Systemd introdujo (o popularizó) la activación por sockets.
Tomemos como ejemplo snapd.socket o docker.socket.
Cuando ves un servicio acabado en .socket, significa que systemd ha creado el socket de escucha (ya sea TCP o un socket UNIX en /run/) antes de iniciar el servicio real.
# Verificar el estado de la unidad socket systemctl status snapd.socket
El flujo es el siguiente:
- Systemd escucha en el puerto/archivo.
- Llega una petición.
- Systemd "despierta" al servicio real (snapd.service) y le pasa la conexión.
¿Por qué es vital saber esto? A veces intentamos reiniciar un servicio (systemctl restart servicio) y vemos que el error persiste o el puerto sigue ocupado. Tip: A menudo es el .socket el que mantiene la conexión o el que debes reiniciar si has cambiado la configuración del puerto, no solo el .service.
3. lsof: La navaja suiza de la auditoría
En UNIX/Linux, "todo es un fichero". Una conexión TCP es un fichero, una librería compartida es un fichero, y un directorio es un fichero. Por eso, lsof (List Open Files) es quizás la herramienta más potente para entender qué está pasando ahora mismo.
Vamos a darle la potencia que merece:
A. Ver quién ocupa un puerto específico (sin netstat/ss):
lsof -i :80
B. Ver qué está haciendo un usuario sospechoso o específico:
lsof -u www-data
C. El caso del "Disco lleno fantasma": ¿Te ha pasado que df -h dice que el disco está lleno, pero borras archivos y el espacio no se libera? Eso es porque un proceso tiene el archivo "abierto" (marcado como deleted pero retenido en memoria).
lsof +L1
Este comando te mostrará los archivos eliminados que siguen ocupando espacio porque un proceso los tiene agarrados. Matar ese proceso liberará el espacio instantáneamente.
Conclusión
Pasar de usuario a SysAdmin implica dejar de ver el sistema como una caja negra. Herramientas como ps -eLf, el entendimiento de las unidades .socket y el dominio de lsof nos dan la visión de rayos X necesaria para mantener infraestructuras robustas y eficientes.
¿Tienes algún flag favorito de ps o un truco con lsof que te haya salvado la vida? Compártelo en los comentarios.
