Gestionar servicios con systemd: guía total de systemctl

En los sistemas Linux modernos, systemd y su herramienta systemctl son el corazón de la gestión de servicios y del propio arranque. Si te mueves por servidores o escritorios a diario, dominar estas utilidades te permitirá arrancar, parar, depurar y automatizar servicios con soltura.

A lo largo de esta guía vas a encontrar un resumen completo y práctico para gestionar servicios con systemd: desde lo básico (start, stop, enable) hasta opciones avanzadas como aislar objetivos, editar unidades con overrides, analizar el arranque o incluso activarlo en WSL. Todo ello con matices de compatibilidad entre distribuciones y otros sistemas init para que no te pille a contrapié.

¿Qué es systemd y cómo organiza el sistema?

En pocas palabras, systemd es el sistema init y gestor de servicios que se ejecuta como PID 1 y coordina el arranque y el ciclo de vida de procesos de usuario. En su ecosistema, las piezas clave son las «unidades» (units), que representan recursos gestionables como servicios, sockets, puntos de montaje, dispositivos o destinos (targets).

Las unidades se describen con archivos de unidad con sufijos que indican su tipo: .service (servicios), .socket (sockets), .target (estados del sistema), entre otros. Estos archivos viven en rutas como /lib/systemd/system y /etc/systemd/system, y pueden verse, listarse y modificarse con systemctl.

Además de systemctl, el ecosistema se completa con utilidades como journalctl (registros), loginctl (sesiones), hostnamectl, localectl, timedatectl o herramientas de inspección como systemd-cgls. Todo suma para una administración más fina y centralizada.

Si necesitas cambiar ajustes globales por defecto, puedes editar /etc/systemd/system.conf (por ejemplo, DefaultTimeoutStartSec) y así anular valores de compilación en todo el sistema sin tocar unidad por unidad.

Arrancar, parar, reiniciar y recargar servicios

El día a día empieza por lo básico: iniciar y detener servicios. Usa sudo systemctl start nombre.service para arrancar y sudo systemctl stop nombre.service para parar. El sufijo .service es opcional; systemd es listo y suele inferirlo. En entornos Windows existen comandos equivalentes para controlar procesos y servicios en Windows.

Cuando haces cambios de configuración, suele tocar reiniciar con sudo systemctl restart nombre.service. Si el servicio admite recarga en caliente, ahorras un corte con sudo systemctl reload. Si no sabes si recarga o no, tira de reload-or-restart y listo.

Ten en cuenta que algunos daemons están pensados para reaparecer tras un stop por su propia política de reinicio. Es habitual en piezas de infraestructura como systemd-networkd, así que no te sorprendas si vuelve a levantarse.

Ojo con las variantes entre distros: en Ubuntu de escritorio es habitual trabajar con NetworkManager, así que comandos como el estado de red podrían consultarse en NetworkManager.service en lugar de systemd-networkd.service.

Habilitar, deshabilitar y comprobar el estado

Para que un servicio arranque automáticamente con el sistema, usa sudo systemctl enable nombre.service. Esto crea enlaces simbólicos desde su archivo de unidad hacia las rutas .../target.wants del objetivo correspondiente. En Windows hay guías sobre qué servicios no tocar, por ejemplo servicios de Windows 11 que no deberías desactivar.

Si no lo quieres en el arranque, deshabilítalo con sudo systemctl disable. Recuerda que enable/disable no arrancan ni paran el servicio en la sesión actual; combinarás enable/disable con start/stop según convenga.

Para revisar el estado en detalle, systemctl status te ofrece carga, actividad, PID, cgroup y últimas líneas de log de la unidad. Si solo quieres un veredicto rápido: systemctl is-active (running o no), systemctl is-enabled (enabled o disabled) y systemctl is-failed (failed, inactive, unknown) con códigos de salida prácticos para scripts.

Explorar el sistema: list-units y list-unit-files

Cuando necesitas una panorámica, systemctl list-units muestra las unidades activas. Verás columnas UNIT, LOAD, ACTIVE, SUB y DESCRIPTION para ubicar de un vistazo qué está ocurriendo. En Windows, el comando listar procesos en Windows con tasklist ofrece una visión similar.

Si quieres ser más exhaustivo, añade –all para incluir inactivas, filtra por estado con --state= y por tipo con --type=service. Así puedes listar, por ejemplo, todas las unidades de servicio independientemente de su actividad.

Para ver lo que hay instalado y su política de arranque, systemctl list-unit-files enumera los archivos de unidad con estado: enabled, disabled, static o masked. «Static» indica unidades sin sección , pensadas para ser dependencias o de ejecución puntual.

Inspeccionar unidades, dependencias y propiedades

Con systemctl cat nombre.service verás exactamente el archivo de unidad que systemd ha cargado (con merges de overrides). Ideal para revisar qué directivas están activas de verdad.

Las dependencias se visualizan con systemctl list-dependencies. Puedes añadir --all para recursividad, --reverse para dependencias inversas, o --before/--after para el orden relativo entre unidades.

Si necesitas detalle a bajo nivel, systemctl show vuelca propiedades clave en formato clave=valor. Para algo concreto, usa -p Propiedad y obtienes solo lo que te interesa (por ejemplo, conflictos o relaciones de orden).

Cuando un servicio no debe arrancar ni por asomo, enmascáralo con sudo systemctl mask nombre.service (apunta a /dev/null). Luego, solo unmask lo devuelve a su estado anterior. Un enmascarado bloquea arranques manuales y automáticos. En entornos Windows también puedes restaurar servicios dañados desde la consola de servicios, por ejemplo restaurar servicios eliminados desde services.msc.

Editar unidades: overrides y recargas del daemon

Para personalizar sin tocar el archivo original, systemctl edit nombre.service abre un override en /etc/systemd/system/nombre.service.d/override.conf. Lo que pongas ahí prevalece sin perder la base del proveedor.

Si quieres reescribir la unidad completa, usa –full y guardará una copia en /etc/systemd/system. Cuando elimines overrides o unidades personalizadas, recuerda recargar el daemon con sudo systemctl daemon-reload para que deje de referenciarlas.

Si ya no necesitas tus cambios, puedes borrar el directorio .d del override o la unidad completa en /etc/systemd/system. Tras ello, un daemon-reload y el sistema volverá a las definiciones del sistema base.

Objetivos (targets) y relación con runlevels

Los targets representan estados del sistema (por ejemplo, multi-user.target o graphical.target) y agrupan unidades necesarias para alcanzar ese estado. Se parecen a los antiguos runlevels, pero son más flexibles y componibles.

Consulta el objetivo por defecto con systemctl get-default y cámbialo con set-default (por ejemplo, graphical.target para iniciar en entorno gráfico). Puedes listar objetivos instalados con list-unit-files --type=target y activos con list-units --type=target.

Si necesitas conmutar de forma drástica, isolate detiene lo que no pertenece al objetivo y activa sus dependencias. Antes, conviene revisar list-dependencies del target para no tumbar algo crítico sin querer.

Además, systemctl expone atajos con aviso a usuarios logados: rescue (modo monousuario), halt, poweroff y reboot. En muchas máquinas, los comandos tradicionales como reboot ya están enlazados a systemd.

Crear tu propio servicio (.service) paso a paso

Para un servicio a medida, crea la unidad en /etc/systemd/system. Por ejemplo, ttrssupdate.service podría contener una descripción, dependencias, el usuario de ejecución y el comando a lanzar.

Un ejemplo típico sería algo así (ajusta rutas reales): con Description, After, User, ExecStart y WantedBy defines lo esencial para que arranque con el sistema multiusuario.

Sobre permisos y propiedad, es importante que el archivo pertenezca a root y tenga permisos coherentes. Evita permisos demasiado permisivos; aunque algunos ejemplos muestran chmod 777, la práctica recomendada es más restrictiva para no abrir la puerta a problemas de seguridad.

Tras crear o modificar la unidad, ejecuta sudo systemctl daemon-reload, habilita con enable y arranca con start. A partir de ahí, podrás stop, restart y consultar status. Para depurar, journalctl -u tu-servicio.service te mostrará los logs asociados.

Equivalencias con SysV y otros inits

Si vienes de SysV, piensa en systemctl start/stop/restart/reload/status como sustitutos de service nombre start/stop/.... Para la parte de arranque, enable/disable reemplaza a chkconfig on/off, y list-unit-files ofrece una visión global de qué está activado.

En sistemas antiguos, puedes encontrarte con service –status-all, que lista daemons con marcas (activo), (inactivo) o (desconocido). Con Upstart (Ubuntu 14.04, RHEL6) se usa initctl list para ver estados como running, stopped o waiting.

En entornos que usan OpenRC (Gentoo, Alpine), rc-status muestra servicios por runlevel con estados started/stopped/failed/crashed. Incluso puedes consultar el runlevel actual con rc runlevel. Para tareas avanzadas de administración de procesos en Windows, también existen herramientas de terceros, por ejemplo usar Process Hacker para gestionar la prioridad.

Diagnóstico, logs y rendimiento del arranque

Para verificar definiciones, systemd-analyze dispone de funciones de comprobación y análisis. Puedes obtener una radiografía del arranque, ver qué tardó más y dibujar un SVG.

Comandos habituales: systemd-analyze blame (tiempos por servicio), systemd-analyze critical-chain (cadena crítica de dependencias) y systemd-analyze plot (genera un .svg con la línea temporal del boot).

Cuando un servicio falla, empieza por journalctl -u nombre.service para ver errores y advertencias. Puedes listar unidades fallidas y, si el apagado o reinicio se eternizan, busca si hay trabajos colgados y cancélalos antes de volver a intentarlo.

Si editas o creas unidades nuevas, no olvides systemd-analyze verify para detectar errores de sintaxis o referencias a archivos inexistentes antes de habilitar e iniciar el servicio.

Buenas prácticas de administración

En archivos de unidad, usa siempre rutas absolutas en ExecStart/ExecReload y ficheros de configuración. No confíes en variables de entorno como $PATH porque systemd no las considerará como lo haría tu shell.

Define ExecReload si tu servicio soporta recarga dinámica. Así podrás usar systemctl reload en caliente sin reiniciar, algo clave en servidores con alta disponibilidad.

Configura RestartSec junto con las políticas de Restart para evitar bucles de reinicio frenéticos. Un pequeño retardo ayuda a estabilizar dependencias y recursos compartidos.

Documenta y supervisa: guarda listados como systemctl list-unit-files –type service –all > services.txt, mapea dependencias con list-dependencies --reverse y monitoriza estado y consumo. Complementa con Prometheus/Grafana o soluciones APM si tu caso lo requiere.

En equipos remotos críticos, desactiva el modo de emergencia si te puede dejar sin red por un error de configuración. Y, por supuesto, valida cambios en staging antes de tocarlos en producción.

Compatibilidad, adopción y visión empresarial

Aunque hoy systemd domina en la mayoría de distribuciones, no es universal. Fedora lo incorporó pronto; Debian lo usa desde la versión 8; RHEL y CentOS desde RHEL 7; Ubuntu lo adoptó en 15.04; Arch y openSUSE llevan años con él, entre otras.

No todo han sido aplausos: se critica su complejidad y alcance, su potencial efecto de dependencia en el ecosistema y cierto alejamiento de la filosofía Unix minimalista. Para admins noveles, la curva de aprendizaje puede parecer empinada.

Entre las desventajas prácticas: permisos y seguridad si no se configuran bien, posibles conflictos de dependencias, arranques más lentos por timeouts mal ajustados o roturas tras actualizaciones si las unidades no se mantienen.

Dicho esto, en entornos corporativos aporta homogeneidad, telemetría y control. Su modularidad, los registros integrados y el modelado declarativo de dependencias facilitan operar a escala y reducir el tiempo medio de reparación.

Systemd en WSL: cómo activarlo y qué cambia

Si trabajas en Windows con WSL 2, ahora puedes habilitar systemd para acercarte aún más a un Linux bare-metal. En Ubuntu actual instalado con wsl --install ya viene por defecto.

Para otras distros en WSL 2, edita /etc/wsl.conf y añade: en una línea y systemd=true en otra. Cierra y ejecuta wsl.exe –shutdown en PowerShell para reiniciar WSL; al volver, comprueba con systemctl status.

En Debian/Ubuntu/Kali, asegúrate de tener systemd y systemd-sysv instalados. Importante: al ceder el PID 1 a systemd, WSL ajusta su arquitectura interna; aun así, los servicios no mantienen la instancia de WSL viva indefinidamente, igual que antes.

Para quien desarrolle con snaps, microk8s u otros componentes que dependen de systemd, esta integración reduce fricciones y acerca el comportamiento al que tendrás en producción.

Conviene recordar que con systemd también dispones de utilidades complementarias como journalctl para el diario, o systemd-analyze para perfilar el arranque y verificar unidades. Con una pizca de orden y unas cuantas buenas prácticas, se convierte en un aliado muy potente para admins y devops.

Artículo relacionado:

Cómo modificar servicios en Windows 11: control total, seguridad y rendimiento

Isaac

Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.