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

📅 Actualizado en febrero 2026 ✍️ Ángel López 📊 Nivel: Avanzado ⏱️ 15 min de lectura
📋 Contenido de esta unidad
  1. ¿Qué es systemd?
  2. systemctl: comandos esenciales
  3. Anatomía de un unit file
  4. Crear servicios personalizados
  5. Targets y niveles de arranque
  6. journalctl: logs del sistema
  7. ⏱️ Timers: alternativa moderna a cron
  8. Análisis y optimización del arranque
  9. Ejercicios prácticos
  10. Errores frecuentes y soluciones

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ísticaSysVinit (antiguo)Systemd (moderno)
ArranqueSecuencial (lento)Paralelo (rápido)
ConfiguraciónScripts de shellUnit files declarativos
DependenciasManual (números de orden)Automáticas (After=, Requires=)
SupervisiónNo (si falla, queda muerto)Sí (Restart=on-failure)
LogsArchivos de texto dispersosjournald centralizado y estructurado
ActivaciónSolo en arranqueSocket, 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)
DirectivaSecciónSignificado
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 systemdRunlevel SysVinitDescripción
poweroff.target0Apagar el sistema
rescue.target1Modo rescate (un solo usuario, sin red)
multi-user.target3Multiusuario con red, sin interfaz gráfica
graphical.target5Multiusuario con interfaz gráfica
reboot.target6Reiniciar 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

ErrorCausaSolución
Failed to start: Unit not foundTypo en nombre o archivo no existeVerificar nombre en /etc/systemd/system/
Main process exited, code=exited, status=203El binario no existe o sin permisosVerificar ruta en ExecStart y chmod +x
code=exited, status=217/USEREl usuario especificado en User= no existeCrear el usuario: sudo useradd -r usuario
Cambios en unit file no se aplicanFalta recargar la configuraciónsudo systemctl daemon-reload
El servicio se reinicia en bucleRestart= sin StartLimitBurstAñadir StartLimitBurst=5 y StartLimitIntervalSec=60
Timer no se ejecutaTimer habilitado pero servicio no existeEl .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.
★ ★ ★ ★ ★ Valora este artículo

💬 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!

DESCARGA GRATUITA

Guía de iniciación a Linux

Las cuatro lecciones más consultadas del curso, en un PDF de 35 páginas que puedes leer sin conexión: qué es Linux, cómo descargarlo y verificar la descarga, qué distribución elegir y la instalación completa de Linux Mint paso a paso.

Te escribiremos para que confirmes tu correo: la descarga empieza en ese mismo clic. Sin confirmar, tu dirección no se da de alta en ninguna lista. Puedes darte de baja cuando quieras.

🎓 ¿Se puede aprender Linux con un curso bonificado por FUNDAE?

Sí. La administración de sistemas y servidores Linux es formación 100 % bonificable por FUNDAE para trabajadores de empresas españolas. Ciberaula, centro acreditado desde 1997, la imparte con tutor personal.

Administración de Servidores Linux para Empresas: de Cero a Nivel Avanzado (40 h) →

También te puede encajar: Administración de Sistemas Linux y Shell Script para Empresas → · Bash Scripting y Terminal Linux: Automatización de Sistemas →

Ver todos los cursos de Linux bonificados del catálogo →  ·  Ciberaula · Centro acreditado FUNDAE (Reg. 99000171) · 91 530 33 87 · admision@ciberaula.com

💻 Formación en Linux y sistemas, bonificable por tu empresa

Si trabajas en una empresa española puedes formarte con coste bonificado a través del crédito de formación FUNDAE. Consulta el catálogo completo de cursos bonificados para empresas en Ciberaula, centro acreditado desde 1997.