LinuxParty

Systemd: Units y Targets; uso de systemctl y compatibilidad con SysV

Desde su adopción en muchas distribuciones Linux, systemd se ha convertido en el sistema de inicialización predominante. En este artículo veremos los principales tipos de unidades (units) que usa systemd, cómo funcionan los targets (equivalentes modernos a los antiguos runlevels), y cómo usar systemctl para gestionarlo de forma segura y eficiente, incluyendo algunas buenas prácticas actualizadas a 2025.

Unidades de systemd (Units)

systemd define varios tipos de unidades, cada una representando un recurso o servicio del sistema. Cada unidad se describe en un fichero .service, .socket, .mount, etc., normalmente ubicado en /usr/lib/systemd/system/ o /etc/systemd/system/.

Los tipos más comunes son:

• service: demonios que pueden iniciarse, detenerse, reiniciarse o recargarse.
• socket: sockets de red o de sistema de archivos. Suelen activar automáticamente un .service asociado cuando hay conexión.
• device: dispositivos del árbol de dispositivos de Linux, normalmente integrados con udev.
• mount: puntos de montaje del sistema de ficheros.
• automount: puntos de montaje que se activan automáticamente al acceder al recurso.
• swap: áreas de intercambio configuradas en el sistema.
• timer: tareas programadas que reemplazan o complementan al clásico cron.
• target: agrupaciones lógicas de otras unidades (similar al concepto de runlevel).
• snapshot: capturas del estado de las unidades en un momento concreto (uso más avanzado).

Targets: el reemplazo moderno de los runlevels

En lugar de los antiguos runlevels numerados (0–6) de SysV, systemd usa targets con nombre, lo que aporta mayor flexibilidad a la hora de definir diferentes escenarios de arranque, apagado, modos multiusuario, entorno gráfico, etc.

Algunos targets importantes son:

• default.target: objetivo que se arranca por defecto (normalmente enlazado a otro target, como graphical.target o multi-user.target).
• multi-user.target: modo multiusuario sin entorno gráfico (similar al antiguo runlevel 3).
• graphical.target: entorno gráfico completo (similar al antiguo runlevel 5).
• rescue.target: modo de rescate, similar al runlevel 1 (modo monousuario).
• emergency.target: modo de emergencia, aún más minimalista, para tareas de recuperación críticas.
• reboot.target y poweroff.target: usados para reiniciar o apagar el sistema.

Para ver los targets disponibles en tu sistema, puedes usar:

systemctl list-units --type=target

Uso básico de systemctl

La herramienta de administración principal es systemctl, que reemplaza y amplía a los clásicos comandos service y chkconfig. Con ella puedes arrancar, detener, reiniciar servicios, habilitarlos o deshabilitarlos en el arranque, consultar su estado y ver qué unidades existen en el sistema.

Listar unidades y archivos de unidades

# Listar todos los archivos de unidad instalados (enabled, disabled, static…)
systemctl list-unit-files --all

# Listar servicios cargados (activos e inactivos)
systemctl list-units --type=service --all

# Listar targets activos
systemctl list-units --type=target

Gestionar servicios

# Iniciar, detener, reiniciar y recargar un servicio
systemctl start nombre_servicio
systemctl stop nombre_servicio
systemctl restart nombre_servicio
systemctl reload nombre_servicio

# Ver el estado de un servicio (incluye últimos logs)
systemctl status nombre_servicio

Por ejemplo, para gestionar el servidor web Apache (httpd en muchas distribuciones):

systemctl start httpd
systemctl status httpd
systemctl enable httpd   # habilitar al arranque
systemctl disable httpd  # deshabilitar al arranque

Cambiar de target (modo de funcionamiento)

Para cambiar a un target concreto (equivalente a cambiar de runlevel), se usa isolate. Por ejemplo, para cambiar al modo gráfico:

systemctl isolate graphical.target

Para ver el target por defecto y cambiarlo:

# Mostrar el target por defecto
systemctl get-default

# Establecer multiusuario (sin entorno gráfico) como target por defecto
systemctl set-default multi-user.target

Ver dependencias y wants de un target

Cada target puede “reclamar” otras unidades mediante directivas como Wants= o Requires=. Para ver qué unidades quiere un target:

systemctl show -p Wants multi-user.target

Además, los targets suelen tener directorios .wants/ y .requires/ que contienen enlaces simbólicos a los servicios asociados. Por ejemplo:

ls /etc/systemd/system/multi-user.target.wants/

Compatibilidad con scripts SysV init

systemd mantiene compatibilidad con muchos scripts de init antiguos. Los scripts en /etc/init.d/ siguen funcionando en la mayoría de distribuciones: systemd genera unidades “compatibles” para ellos de forma automática.

Por ejemplo, puedes seguir usando:

/etc/init.d/mi_servicio start

pero se recomienda usar la forma moderna:

systemctl start mi_servicio

Si tu servicio sólo existe como script SysV y no tiene unidad propia de systemd, considera crear un archivo .service dedicado. Esto te permitirá:

• Definir dependencias explícitas (After=, Requires=, etc.).
• Integrar correctamente los logs vía journalctl.
• Controlar de forma más fina el reinicio, tiempo de espera, usuario/grupo del servicio, etc.

Logs con journalctl

Uno de los puntos fuertes de systemd es su integración con el sistema de logs mediante journald. En lugar de revisar múltiples archivos en /var/log/, puedes consultar la mayoría de eventos con:

# Logs desde el último arranque
journalctl -b

# Logs de una unidad concreta
journalctl -u nombre_servicio

# Seguir logs en tiempo real (similar a tail -f)
journalctl -u nombre_servicio -f

Novedades y buenas prácticas (2025)

Algunos consejos actualizados para trabajar con systemd en sistemas modernos:

• Prefiere crear unidades .service en /etc/systemd/system/ antes que depender de scripts en /etc/init.d/.
• Después de modificar o añadir unidades, ejecuta siempre systemctl daemon-reload para forzar a systemd a recargar la configuración.
• Para servicios críticos, configura directivas como Restart=on-failure y límites de recursos (MemoryMax=, CPUQuota=, etc.).
• Usa systemctl status junto con journalctl para diagnosticar rápidamente por qué un servicio falla o no arranca.
• Evita cambiar el target por defecto sin entender sus implicaciones; prueba primero con isolate y comprueba que todo funciona.
• Cuando migres servidores antiguos basados en SysV, planifica la sustitución progresiva de scripts de init por unidades systemd nativas.

Conclusión

systemd y systemctl ofrecen un marco moderno y potente para gestionar la inicialización y los servicios en Linux. Aunque mantienen compatibilidad con los scripts SysV init, su diseño basado en unidades, targets y una gestión de dependencias más explícita los convierte en herramientas fundamentales en cualquier sistema Linux actual.

Dominar systemctl, entender los diferentes tipos de unidades y aprender a usar journalctl para diagnosticar problemas te permitirá administrar tu sistema de forma mucho más cómoda, robusta y eficiente.

¿Quieres tu propio servicio?

Mira nuestro ejemplo:

🧠 Cómo forzar evitar distracciones con tus propios scripts en Linux