🥇 Systemd en Linux: gestión de servicios y arranque

Systemd es el corazón de las distribuciones Linux modernas. Cada vez que enciendes tu ordenador, systemd arranca el sistema, monta discos, inicia servicios, gestiona la red y supervisa que todo siga funcionando. Dominar systemd es imprescindible para cualquier administrador de sistemas, y esta guía te enseña desde los comandos básicos hasta la creación de servicios y timers profesionales.

⚙️ ¿Qué es systemd?

Systemd es un sistema de inicialización (PID 1) y gestor de servicios creado por Lennart Poettering y Kay Sievers en 2010. Reemplazó a SysVinit en prácticamente todas las distribuciones principales: Ubuntu, Debian, Fedora, RHEL, Arch, openSUSE y muchas más.

A diferencia de SysVinit, que arrancaba los servicios secuencialmente mediante scripts de shell, systemd arranca servicios en paralelo, gestiona dependencias automáticamente, supervisa procesos, ofrece activación por socket y por bus, y centraliza los logs con journald. El resultado es un arranque significativamente más rápido y una gestión de servicios más robusta y predecible.

Característica	SysVinit (antiguo)	Systemd (moderno)
Arranque	Secuencial (lento)	Paralelo (rápido)
Configuración	Scripts de shell	Unit files declarativos
Dependencias	Manual (números de orden)	Automáticas (After=, Requires=)
Supervisión	No (si falla, queda muerto)	Sí (Restart=on-failure)
Logs	Archivos de texto dispersos	journald centralizado y estructurado
Activación	Solo en arranque	Socket, bus, timer, path, dispositivo

💡 ¿Por qué genera controversia?

Systemd es el proyecto más debatido en la historia de Linux. Sus defensores valoran la velocidad, fiabilidad y gestión unificada. Sus detractores critican que viola la filosofía Unix de «hacer una cosa bien», ya que systemd abarca init, logs, red, timers, contenedores y más. Independientemente de la opinión, es el estándar de facto y hay que dominarlo.

🎛️ systemctl: comandos esenciales

systemctl es el comando principal para interactuar con systemd. Con él gestionas servicios, consultas estados, habilitas arranque automático y mucho más.

terminal — Comandos básicos de systemctl
# Estado de un servicio
            sudo systemctl status nginx

            # Iniciar / Parar / Reiniciar
            sudo systemctl start nginx
            sudo systemctl stop nginx
            sudo systemctl restart nginx

            # Recargar configuración sin cortar conexiones
            sudo systemctl reload nginx

            # Habilitar arranque automático
            sudo systemctl enable nginx

            # Habilitar Y arrancar en un solo comando
            sudo systemctl enable --now nginx

            # Deshabilitar arranque automático
            sudo systemctl disable nginx

            # ¿Está activo? ¿Está habilitado?
            systemctl is-active nginx
            systemctl is-enabled nginx

            # Listar todos los servicios activos
            systemctl list-units --type=service --state=running

            # Listar servicios fallidos
            systemctl list-units --type=service --state=failed

            # Ver dependencias de un servicio
            systemctl list-dependencies nginx

📄 Anatomía de un unit file

Los unit files son archivos de configuración declarativos que describen los recursos que systemd gestiona. Cada unit file tiene extensión según su tipo: .service, .timer, .mount, .socket, .target, etc.

estructura de un .service — Las tres secciones
# [Unit] — Metadatos y dependencias
            [Unit]
            Description=Mi aplicación web
            Documentation=https://docs.miapp.com
            After=network.target mysql.service    # Arrancar DESPUÉS de red y MySQL
            Requires=mysql.service                # Falla si MySQL no está activo
            Wants=redis.service                   # Preferible que Redis esté, pero no obligatorio

            # [Service] — Cómo ejecutar el servicio
            [Service]
            Type=simple                           # El proceso principal es el que se ejecuta
            User=webapp                           # Ejecutar como este usuario (nunca root)
            Group=webapp
            WorkingDirectory=/opt/miapp
            ExecStart=/opt/miapp/bin/servidor     # Comando de inicio
            ExecReload=/bin/kill -HUP $MAINPID    # Comando de recarga
            Restart=on-failure                    # Reiniciar automáticamente si falla
            RestartSec=5                          # Esperar 5 segundos antes de reiniciar
            StandardOutput=journal                # Enviar stdout a journald
            StandardError=journal                 # Enviar stderr a journald

            # [Install] — Cuándo activar el servicio
            [Install]
            WantedBy=multi-user.target            # Arrancar en modo multiusuario (normal)

Directiva	Sección	Significado
`After=`	[Unit]	Arrancar después de estas unidades
`Requires=`	[Unit]	Dependencia fuerte: falla si la dependencia falla
`Wants=`	[Unit]	Dependencia débil: preferible pero no obligatoria
`Type=`	[Service]	simple, forking, oneshot, notify, idle
`ExecStart=`	[Service]	Comando para iniciar el servicio
`Restart=`	[Service]	no, on-failure, on-abnormal, always
`User=`	[Service]	Usuario con el que se ejecuta (no usar root)
`WantedBy=`	[Install]	Target que activa este servicio

🔧 Crear servicios personalizados

Crear tu propio servicio systemd es la forma profesional de ejecutar aplicaciones en un servidor. En lugar de lanzar procesos manualmente con nohup o screen, un servicio systemd arranca automáticamente, se reinicia si falla y queda registrado en los logs.

/etc/systemd/system/miapp.service — Ejemplo: app Node.js
[Unit]
            Description=Mi aplicación Node.js
            After=network.target

            [Service]
            Type=simple
            User=nodeapp
            WorkingDirectory=/opt/miapp
            ExecStart=/usr/bin/node /opt/miapp/server.js
            Restart=on-failure
            RestartSec=10
            Environment=NODE_ENV=production
            Environment=PORT=3000

            # Seguridad: restringir lo que puede hacer el servicio
            NoNewPrivileges=true
            ProtectSystem=strict
            ProtectHome=true
            ReadWritePaths=/opt/miapp/data

            [Install]
            WantedBy=multi-user.target

terminal — Activar el servicio
# Recargar systemd para que detecte el nuevo archivo
            sudo systemctl daemon-reload

            # Habilitar y arrancar
            sudo systemctl enable --now miapp

            # Verificar estado
            sudo systemctl status miapp

            # Ver logs del servicio
            sudo journalctl -u miapp -f

✅ Directivas de seguridad en servicios

Systemd ofrece sandboxing nativo para servicios. Usa ProtectSystem=strict (sistema de archivos de solo lectura), ProtectHome=true (sin acceso a /home), NoNewPrivileges=true (no puede escalar privilegios) y ReadWritePaths= para permitir solo los directorios que necesita. Esto limita el daño si el servicio es comprometido.

🎯 Targets y niveles de arranque

Los targets de systemd reemplazan los antiguos runlevels de SysVinit. Un target agrupa un conjunto de servicios que deben estar activos para un estado concreto del sistema.

Target systemd	Runlevel SysVinit	Descripción
`poweroff.target`	0	Apagar el sistema
`rescue.target`	1	Modo rescate (un solo usuario, sin red)
`multi-user.target`	3	Multiusuario con red, sin interfaz gráfica
`graphical.target`	5	Multiusuario con interfaz gráfica
`reboot.target`	6	Reiniciar el sistema
`emergency.target`	—	Shell de emergencia mínimo

terminal — Gestión de targets
# Ver target actual
            systemctl get-default

            # Cambiar a modo texto (servidores)
            sudo systemctl set-default multi-user.target

            # Cambiar a modo gráfico (escritorio)
            sudo systemctl set-default graphical.target

            # Cambiar de target en caliente (sin reiniciar)
            sudo systemctl isolate multi-user.target

📋 journalctl: logs del sistema

journalctl es la herramienta de consulta de logs de systemd. Centraliza todos los mensajes del kernel, servicios, arranque y aplicaciones en un formato estructurado y consultable con filtros potentes.

terminal — journalctl: consultas esenciales
# Logs del sistema (más recientes primero)
            journalctl -r

            # Logs de un servicio específico
            journalctl -u nginx

            # Logs en tiempo real (como tail -f)
            journalctl -u nginx -f

            # Solo errores y superior
            journalctl -p err

            # Filtrar por tiempo
            journalctl --since "2026-02-25 10:00" --until "2026-02-25 12:00"
            journalctl --since "1 hour ago"
            journalctl --since today

            # Solo el último arranque
            journalctl -b

            # Logs del kernel
            journalctl -k

            # Espacio usado por los logs
            journalctl --disk-usage

            # Limpiar logs antiguos (mantener solo 500 MB)
            sudo journalctl --vacuum-size=500M

            # Limpiar logs de más de 30 días
            sudo journalctl --vacuum-time=30d

⏱️ Timers: alternativa moderna a cron

Los timers de systemd son la alternativa moderna a cron. Un timer es una unidad .timer que activa un servicio .service en momentos o intervalos definidos. Sus ventajas: logs integrados con journalctl, ejecución recuperable si el sistema estaba apagado, y dependencias de systemd.

/etc/systemd/system/backup.service
[Unit]
            Description=Backup diario de datos

            [Service]
            Type=oneshot
            ExecStart=/opt/scripts/backup.sh
            User=backup

/etc/systemd/system/backup.timer
[Unit]
            Description=Ejecutar backup cada día a las 3:00

            [Timer]
            OnCalendar=*-*-* 03:00:00           # Cada día a las 3 AM
            Persistent=true                      # Si estaba apagado, ejecutar al arrancar
            RandomizedDelaySec=900               # Añadir hasta 15 min de retraso aleatorio

            [Install]
            WantedBy=timers.target

terminal — Gestionar timers
# Recargar, habilitar y activar
            sudo systemctl daemon-reload
            sudo systemctl enable --now backup.timer

            # Listar todos los timers activos
            systemctl list-timers --all

            # Ver cuándo se ejecutará la próxima vez
            systemctl list-timers backup.timer

            # Ejecutar manualmente (para probar)
            sudo systemctl start backup.service

            # Ver logs de las ejecuciones
            journalctl -u backup.service

✅ Sintaxis de OnCalendar

La sintaxis es flexible: daily (cada día), weekly (cada lunes), hourly (cada hora), *-*-* 03:00:00 (cada día a las 3), Mon *-*-* 09:00:00 (cada lunes a las 9). Puedes verificar la expresión con systemd-analyze calendar "Mon *-*-* 09:00:00".

🚀 Análisis y optimización del arranque

Systemd incluye herramientas para analizar el arranque del sistema y detectar cuellos de botella. Esto es especialmente útil en servidores donde cada segundo de arranque importa.

terminal — Análisis del arranque
# Tiempo total de arranque
            systemd-analyze

            # Desglose por servicio (los más lentos primero)
            systemd-analyze blame | head -15

            # Cadena crítica (la ruta más lenta del arranque)
            systemd-analyze critical-chain

            # Generar gráfico SVG del arranque
            systemd-analyze plot > arranque.svg

            # Verificar un unit file (buscar errores)
            systemd-analyze verify /etc/systemd/system/miapp.service

✏️ Ejercicios prácticos

Ejercicio 1: Servicio de monitorización

Enunciado: Crea un servicio systemd que ejecute un script cada vez que se inicia. El script debe registrar en /var/log/monitor.log la fecha, el uso de disco y la memoria libre. Configúralo para que se reinicie automáticamente si falla.

▶ Ver solución

/opt/scripts/monitor.sh
#!/bin/bash
            while true; do
            {
            echo "=== $(date) ==="
            echo "Disco:"
            df -h / | tail -1
            echo "Memoria:"
            free -h | grep Mem
            echo ""
            } >> /var/log/monitor.log
            sleep 60
            done

/etc/systemd/system/monitor.service
[Unit]
            Description=Monitor de recursos del sistema
            After=network.target

            [Service]
            Type=simple
            ExecStart=/opt/scripts/monitor.sh
            Restart=on-failure
            RestartSec=10

            [Install]
            WantedBy=multi-user.target

Ejercicio 2: Timer para limpieza de temporales

Enunciado: Crea un timer systemd que ejecute un script de limpieza de archivos temporales cada domingo a las 4:00 AM. El script debe eliminar archivos de más de 7 días en /tmp.

▶ Ver solución

limpieza.service + limpieza.timer
# /etc/systemd/system/limpieza.service
            [Unit]
            Description=Limpieza de archivos temporales

            [Service]
            Type=oneshot
            ExecStart=/usr/bin/find /tmp -type f -mtime +7 -delete

            # /etc/systemd/system/limpieza.timer
            [Unit]
            Description=Limpieza semanal de temporales

            [Timer]
            OnCalendar=Sun *-*-* 04:00:00
            Persistent=true

            [Install]
            WantedBy=timers.target

            # Activar:
            # sudo systemctl daemon-reload
            # sudo systemctl enable --now limpieza.timer

⚠️ Errores frecuentes y soluciones

Error	Causa	Solución
`Failed to start: Unit not found`	Typo en nombre o archivo no existe	Verificar nombre en `/etc/systemd/system/`
`Main process exited, code=exited, status=203`	El binario no existe o sin permisos	Verificar ruta en ExecStart y `chmod +x`
`code=exited, status=217/USER`	El usuario especificado en User= no existe	Crear el usuario: `sudo useradd -r usuario`
Cambios en unit file no se aplican	Falta recargar la configuración	`sudo systemctl daemon-reload`
El servicio se reinicia en bucle	Restart= sin StartLimitBurst	Añadir `StartLimitBurst=5` y `StartLimitIntervalSec=60`
Timer no se ejecuta	Timer habilitado pero servicio no existe	El .timer y el .service deben tener el mismo nombre base

💡 Dónde van los unit files

/etc/systemd/system/ es para servicios del administrador (los tuyos). /lib/systemd/system/ es para servicios de paquetes (no editar directamente). Si necesitas modificar un servicio de paquete, crea un override: sudo systemctl edit nginx abrirá un archivo de sobreescritura parcial sin tocar el original.

❓ Preguntas frecuentes sobre Systemd en Linux: guía completa de gestión de servicios

Las dudas más comunes respondidas de forma clara y directa.

Systemd es el sistema de inicialización (init) y gestor de servicios estándar en la mayoría de distribuciones Linux modernas. Se encarga de arrancar el sistema, gestionar servicios (demonios), montar sistemas de archivos, gestionar logs y mucho más. Reemplazó al antiguo SysVinit por su capacidad de arrancar servicios en paralelo y gestionar dependencias.

SysVinit arrancaba los servicios secuencialmente (uno tras otro) usando scripts en /etc/init.d/. Systemd los arranca en paralelo, gestiona dependencias automáticamente, ofrece activación por socket y supervisa los servicios reiniciándolos si fallan. El resultado es un arranque mucho más rápido y una gestión más robusta.

Un unit file es un archivo de configuración que describe un recurso que systemd gestiona: un servicio (.service), un punto de montaje (.mount), un temporizador (.timer), un socket (.socket), etc. Contiene secciones como [Unit] para metadatos, [Service] para la configuración del servicio y [Install] para definir cuándo se activa.

Crea un archivo .service en /etc/systemd/system/ con las secciones [Unit], [Service] e [Install]. Define el comando de inicio con ExecStart, el usuario con User, y las dependencias con After/Requires. Luego ejecuta systemctl daemon-reload, systemctl enable tu-servicio y systemctl start tu-servicio.

systemctl start inicia el servicio ahora mismo pero no sobrevive a un reinicio. systemctl enable configura el servicio para que se inicie automáticamente en cada arranque, pero no lo inicia inmediatamente. Para ambas cosas: systemctl enable --now servicio.

Los timers son la alternativa moderna de systemd a cron para programar tareas. Un timer (.timer) activa un servicio (.service) en intervalos o momentos específicos. Ventajas sobre cron: logs integrados con journalctl, control de dependencias, ejecución diferida si el sistema estaba apagado, y gestión uniforme con systemctl.

Usa journalctl -u nombre-servicio para ver los logs de un servicio específico. Puedes filtrar por tiempo con --since y --until, por prioridad con -p (err, warning, info), seguir en tiempo real con -f, y ver solo el último arranque con -b. Journalctl centraliza todos los logs del sistema en un formato estructurado y consultable.

💬 Foro de discusión

¿Tienes dudas sobre Systemd en Linux: guía completa de gestión de servicios? Comparte tu pregunta con la comunidad.

¿Tienes cuenta? o comenta como invitado ↓

Todavía no hay mensajes. ¡Sé el primero en participar!

🚀 ¿Quieres dominar Linux profesionalmente?

Cursos bonificados por FUNDAE para empresas — formación 100% subvencionada

Ver cursos de Linux →

Systemd en Linux: guía completa de gestión de servicios

⚙️ ¿Qué es systemd?

🎛️ systemctl: comandos esenciales

📄 Anatomía de un unit file

🔧 Crear servicios personalizados

🎯 Targets y niveles de arranque

📋 journalctl: logs del sistema

⏱️ Timers: alternativa moderna a cron

🚀 Análisis y optimización del arranque

✏️ Ejercicios prácticos

Ejercicio 1: Servicio de monitorización

Ejercicio 2: Timer para limpieza de temporales

⚠️ Errores frecuentes y soluciones

❓ Preguntas frecuentes sobre Systemd en Linux: guía completa de gestión de servicios

💬 Foro de discusión

🔑 Recuperar contraseña

Crear cuenta

¿Cómo valorarías tu experiencia aprendiendo en esta sección?

¡Gracias por tu valoración!

⚙️ ¿Qué es systemd?

🎛️ systemctl: comandos esenciales

📄 Anatomía de un unit file

🔧 Crear servicios personalizados

🎯 Targets y niveles de arranque

📋 journalctl: logs del sistema

⏱️ Timers: alternativa moderna a cron

🚀 Análisis y optimización del arranque

✏️ Ejercicios prácticos

Ejercicio 1: Servicio de monitorización

Ejercicio 2: Timer para limpieza de temporales

⚠️ Errores frecuentes y soluciones

❓ Preguntas frecuentes sobre Systemd en Linux: guía completa de gestión de servicios

💬 Foro de discusión

Iniciar sesión

🔑 Recuperar contraseña

Crear cuenta