¿Cuántas veces se ha hecho la «sencilla» pregunta: ¿por qué este servicio no vuelve a arrancar al reiniciar? O ha ejecutado top convencido de que el proceso devorador de memoria aparecerá en la lista — y parece ponerse una capa de invisibilidad? Vamos a ver cómo tomar el control de los servicios y procesos para que los servidores funcionen y los nervios se mantengan en su sitio.
¿Por qué preocuparse por los servicios y procesos?
Los servicios (también «units» o «demonios») y los procesos son los motores del sistema operativo. Si los motores se apagan, el barco no navega. Y si funcionan sin control, consumen combustible y el presupuesto destinado al hosting. Gestionarlos significa administrar los recursos, la seguridad y la tolerancia a fallos de su proyecto.
- Reducción del consumo de CPU y RAM (ahorro de dinero en la nube).
- Aumento de la seguridad: menos servicios en ejecución implica menor superficie atacable.
- Visión clara de lo que ocurre en el servidor: facilita la búsqueda de «fugas».
systemd y systemctl: su mando a distancia personal para los servicios
systemd — no es solo «ese proceso con PID 1», sino todo un ecosistema que arranca el resto, gestiona los registros, vigila dependencias y reinicia lo que cae. Y systemctl es una especie de mando a distancia. Vamos a pulsar botones.
Inicio y parada
Iniciar un servicio en modo manual es facilísimo:
systemctl start nginx.
¿Detenerlo? De forma análoga: systemctl stop nginx.
En esencia, está dando la orden a systemd de «mover la palanca de alimentación» para el archivo unit indicado.
Arranque automático: activar y desactivar
Para que un servicio se inicie en cada reinicio, ejecute systemctl enable nginx. Para desactivar completamente el arranque automático, systemctl disable nginx. Por cierto, enable no inicia el servicio en ese momento, solo crea un enlace simbólico en el directorio /etc/systemd/system/.
Reinicio sin pánico
Cuando ha actualizado la configuración y necesita recargar el servicio sin un apagado largo, use systemctl reload nginx. Si no funciona — systemctl restart nginx, que equivale a «apagar-encender». El reinicio es como Ctrl+Alt+Del, pero para un demonio.
¿Qué hay dentro de un archivo unit?
Un archivo unit es un texto simple en estilo .ini. Ejemplo:
- [Unit] — descripción y dependencias.
- [Service] — qué ejecutar, cómo reiniciar, dónde registrar.
- [Install] — en qué «runlevel» activar.
Puede abrirlo con el habitual cat /lib/systemd/system/nginx.service. No tema: leer archivos unit no provoca dolor de cabeza, a diferencia de los configs JSON con llaves por media pantalla.
ps: instantánea del proceso en su entorno natural
A veces se necesita una «fotografía» de la lista de procesos aquí y ahora — sin animaciones ni guiños. Presentamos ps.
Técnica clásica: ps aux
El comando ps aux muestra absolutamente todo: procesos de cualquier usuario (a — all), u — formato detallado, x — incluyendo demonios sin terminal. Sale una lista larga, pero completa. Truco: añada | grep nginx para no buscar a ojo.
Filtros útiles
- ps -ef — salida alternativa al formato BSD: un poco más de campos, la columna SSID (Session ID), igualmente útil con | grep.
- ps -eo pid,cmd,%mem,%cpu — construimos nuestro informe personalizado.
- ps --sort=-%mem -eo pid,cmd,%mem | head — el top de «devoradores» de memoria en una sola línea.
top y compañía: monitor en tiempo real de la carga del servidor
top — como un monitor cardíaco: parpadea líneas, muestra qué está vivo y qué finge estarlo. Ejecuta simplemente top y verá los porcentajes de CPU, la carga por núcleos, el swap y los candidatos al OOM-killer.
Navegación sin ratón
- h — ayuda; no hace falta buscar en la red cada vez.
- k — «matar» un proceso indicando el PID y la señal (por defecto 15).
- r — cambiar el nice si un proceso se comporta de forma agresiva.
- M — ordenar por memoria, P — por CPU.
- q — salir cuando ya haya visto suficiente.
¿Por qué todos elogian htop?
htop — es como top, pero con mejor experiencia: barras de colores, clic con ratón, árbol horizontal de procesos. En Debian y derivados se instala con apt install htop. La moraleja: los añadidos visuales animan a monitorizar con más frecuencia.
Técnicas combinadas: el detective del sistema en acción
Supongamos que el servicio myapp se cae de repente. Plan de acción:
- systemctl status myapp — comprobamos el último código de salida.
- journalctl -u myapp — leemos el registro. journalctl — la «biblioteca de chismes» de systemd.
- Localizamos el PID, comprobamos con ps -p PID -o pid,cmd,%cpu,%mem.
- Si la memoria se dispara, abrimos top, ordenamos con M y observamos los picos.
- Modificamos la configuración (límites, worker-processes), guardamos y reiniciamos: systemctl restart myapp.
En el 90 % de los casos, la combinación systemctl + journalctl + top encuentra la raíz del problema más rápido que un strace detallado. Y en el 10 % restante — sí, habrá que sacar la artillería pesada ( bpftrace y compañía).
Automatización: scripts, temporizadores y un poco de magia
Todo administrador ha escrito al menos una vez el «morboso» script de cron check_nginx.sh, que cada minuto ejecuta ps y arranca Nginx si ha muerto. La forma moderna es un systemd timer. Crea myapp.service y myapp.timer — y obtiene ejecuciones regulares sin parches. La guía oficial del wiki explica todos los detalles.
Consejos de seguridad y salud del sistema
- No se apresure a enviar kill -9. Primero intente con SIGTERM = 15. systemd enviará automáticamente SIGKILL si la aplicación ignora la petición educada.
- Limite recursos desde el archivo unit: MemoryLimit=512M, CPUShares=1024. Así fija un «techo» por adelantado.
- Use ProtectSystem=strict y PrivateTmp=true — minimizan el daño si un servicio se compromete.
- Siempre que sea posible, ejecute demonios de red bajo un usuario separado (parámetro User= en el archivo unit).
Conclusiones: menos pánico — más control
Gestionar servicios y procesos no es alquimia misteriosa, sino un conjunto de hábitos: revise el estado con systemctl, haga «instantáneas» con ps, observe el ritmo cardíaco con top. Pronto la lógica de estas utilidades encajará como un rompecabezas — y podrá explicar a un compañero por qué «el servidor va lento», en lugar de reiniciarlo nerviosamente por completo.
Cuide el tiempo de actividad y no tema experimentar: Linux perdona, y la experiencia siempre será útil.
