En 03-06 te enseñé ps, kill y nohup, y te dije con todas las letras que nada de eso sirve para gestionar un servicio de verdad. En 03-07 montaste la copia nocturna con cron y te avisé de que existía algo mejor. Esta es la lección donde se saldan las dos promesas, y es el corazón del módulo. Hoy Tramontana Reservas se arranca a mano: si srv-tramontana se reinicia, la aplicación no vuelve; si el proceso 1284 muere, nadie lo levanta; desplegar.sh cambia el enlace simbólico y no reinicia nada; y la copia de las 4:20 depende de una línea de cron sin control real de solapamiento ni registro decente. Al terminar tendrás tramontana.service escrito, endurecido y habilitado, y respaldo_tramontana.sh convertido en un servicio con su timer.

1. Qué es un sistema de init y qué resuelve systemd
2. PID 1, cgroups y los tipos de unidad
3. systemctl: consultar, controlar y habilitar
4. Dónde viven las unidades y qué precedencia tienen
5. Escribir una unidad .service sección por sección
6. Endurecer la unidad y ponerle techo con cgroups v2
7. Targets y niveles de ejecución
8. Timers: el sustituto de cron
9. Analizar el arranque y lanzar trabajos transitorios
10. Caso Tramontana: el servicio, el timer y el despliegue completo

El kernel arranca, monta la raíz y ejecuta un proceso: el init, con PID 1, del que desciende todo lo demás. Su trabajo es levantar el sistema, mantener los servicios vivos y apagarlo con orden.

La consecuencia práctica de los cgroups es enorme: si tu aplicación lanza cinco hijos y uno queda huérfano, systemctl stop los mata a todos, porque el kernel los contabiliza en el mismo grupo de control. Con un fichero PID, ese huérfano seguía escribiendo mientras tú creías haber parado el servicio.

Todo en systemd es una unidad, y el sufijo del fichero dice de qué tipo:

Hay que leer la salida entera:

• Loaded: de qué fichero viene y si está enabled (arranca solo al iniciar la máquina) o disabled. Un servicio puede estar active y disabled: funciona ahora, pero no volverá tras un reinicio.
• Active: active (running) para un demonio, active (exited) para un oneshot que terminó bien, failed con el código de salida y la señal si murió.
• Tasks, Memory, CGroup: consumo real del cgroup y árbol completo de procesos, hijos incluidos, no una estimación. Las últimas líneas son log del journal, que exprimirás en 05-06.

Aquí se cierra el círculo con 02-06:

enable crea el enlace dentro del .wants del target que indique [Install] y disable lo borra: nada más. Por eso enable no arranca el servicio (para eso, enable --now) y disable no lo para. mask enlaza la unidad a /dev/null, y así no se puede arrancar en absoluto —ni a mano, ni como dependencia, ni por un socket—, que es lo que quieres durante un mantenimiento; unmask lo revierte.

sudo systemctl daemon-reload es obligatorio tras crear o editar cualquier fichero de unidad: si no, systemd sigue trabajando con la versión anterior en memoria y te volverás loco. Y recargar la configuración no reinicia el servicio: eso es un restart aparte.

edit abre /etc/systemd/system/tramontana.service.d/override.conf, donde escribes solo la sección y las directivas a cambiar. Un drop-in es mejor que editar la unidad original: sobrevive a la actualización del paquete que la trajo, deja explícito qué has cambiado tú y se elimina borrando un fichero. Aviso con las directivas de lista (ExecStart, Environment): para sustituir hay que vaciarlas antes con ExecStart= en blanco, o se acumulan.

Por prioridad decreciente: /etc/systemd/system/ (donde escribes tú), /run/systemd/system/ (unidades transitorias, en RAM) y /lib/systemd/system/ (las de los paquetes). Tus unidades van en /etc/systemd/system/; las de los paquetes no se tocan, se ajustan con drop-ins. Un fichero con el mismo nombre en /etc sustituye por completo al de /lib.

Aquí se lía todo el mundo, porque hay dos ejes independientes: el orden (cuándo arranca respecto a otra unidad) y la dependencia (si la necesita para existir).

El error clásico es poner Requires=postgresql.service y creer que garantiza que la base de datos esté lista antes que tú. No lo garantiza: Requires sin After arranca las dos en paralelo, así que hacen falta las dos directivas. Como norma usa Wants=: si el servicio de logs remoto falla, prefieres que tu aplicación arranque igual.

Un servicio moderno en Go, Java o Python casi siempre es simple o exec: no lo mandes al fondo con & ni uses nohup, porque systemd ya se encarga de eso. Las demás directivas del día a día:

• Restart=: no (por defecto), on-failure (código distinto de cero o señal fatal: la opción correcta para una aplicación), always, on-abnormal.
• RestartSec + StartLimitBurst + StartLimitIntervalSec: reinicia a los 5 s, y si lo hace 5 veces en 300 s se rinde y queda failed. Sin ese límite, una aplicación que no arranca entra en un bucle infinito que consume CPU y llena el log; para volver, systemctl reset-failed.
• TimeoutStopSec y KillMode=mixed: cuánto se espera tras el SIGTERM antes del SIGKILL, y que este alcance a todo el cgroup. Es la secuencia «SIGTERM → esperar → verificar → -9» de 03-06, automatizada.

Suele tener una línea, WantedBy=multi-user.target, y es lo que lee enable para saber en qué directorio .wants crear el enlace. Una unidad sin [Install] no se puede habilitar: aparecerá como static.

Es una de las cosas más valiosas de systemd, y es gratis: unas líneas dejan tu servicio con muchísima menos superficie de ataque de la que lograrías a mano.

systemd-analyze security tramontana.service puntúa el resultado: la unidad que escribiremos al final de la lección saca 2.9 OK, frente al 9.6 UNSAFE que sacaba sin endurecer. Nota práctica: ProtectSystem=strict romperá tu servicio la primera vez, porque escribe en algún sitio que no has declarado. No lo desactives: mira el log, añade la ruta a ReadWritePaths y vuelve a probar. Ese ejercicio te obliga a saber exactamente dónde escribe tu aplicación.

A la misma sección [Service] pertenecen los límites de recursos, que systemd aplica con cgroups v2:

Ese MemoryMax impide que una fuga de memoria se lleve por delante la base de datos y el propio SSH: al superarlo, el kernel mata dentro del cgroup del servicio y Restart=on-failure lo levanta.

También existe network-online.target, el punto de sincronización que indica que hay red utilizable. systemctl get-default dice cuál es el predeterminado, set-default lo cambia y sudo systemctl isolate rescue.target cambia de target ahora mismo, cortando los servicios que sobran.

Un timer es una unidad que activa otra: por convención, tramontana-respaldo.timer dispara tramontana-respaldo.service (mismo nombre, otro sufijo).

Verifica siempre la expresión antes de confiar en ella:

Otras formas de disparo: OnBootSec=5min (tras arrancar la máquina), OnUnitActiveSec=1h (cada hora desde la última ejecución) y OnStartupSec=. Y expresiones legibles: daily, weekly, Mon..Fri 08:00, *-*-01 03:00 (día 1 de cada mes).

Persistent=true es la razón principal para migrar de cron: si el servidor estaba apagado a las 4:20, la copia se ejecuta en cuanto arranque en lugar de perderse hasta el día siguiente.

blame ordena por duración; critical-chain muestra la cadena que de verdad retrasa el arranque de una unidad concreta, que es lo que importa: un servicio lento del que no depende nadie no retrasa nada. Y systemd-run lanza algo puntual como unidad transitoria, registrado en el journal y con sus límites aplicados, a diferencia de un nohup.

Decisiones que conviene entender: Type=exec porque la aplicación se queda en primer plano y así un binario inexistente se detecta al arrancar; User=svc-tramontana con Group=tramontana, las identidades de 05-01, y UMask=0027 por convención del curso; ReadWritePaths con solo el log y las subidas, porque todo lo demás —incluido /opt/tramontana— debe ser inmutable para la aplicación; y CapabilityBoundingSet= vacío porque escucha en el 8080 (si pasara al 80 se añadiría AmbientCapabilities=CAP_NET_BIND_SERVICE, sustituyendo al setcap de 05-02, que se perdía en cada despliegue).

Type=oneshot porque el script termina, y sin [Install] porque no se habilita: lo dispara el timer, y por eso aparecerá como static. RequiresMountsFor= es la joya de esta unidad: si el volumen LVM de 05-04 no está montado, la copia no se ejecuta en lugar de escribir alegremente en el directorio vacío de /, un fallo silencioso que solo descubrirías el día de la restauración. Nice=10 e IOSchedulingClass=idle hacen que la copia ceda el paso a la aplicación, algo que en 05-07 resultará importante.

inactive (dead) tras un oneshot es éxito: el script terminó con código 0; un failed mostraría el código de salida que definiste en 04-03. Y ese sed final retira la línea de cron, que es la mitad del trabajo que la gente olvida: dejar las dos cosas activas significa dos copias simultáneas peleando por el flock cada madrugada.

La deuda del Módulo 4: tras el ln -sfn atómico, el script comprobaba la salud contra un proceso que seguía ejecutando el release anterior, porque el binario ya estaba cargado en memoria. Ahora:

El sudo systemctl restart funciona sin contraseña interactiva gracias a la regla de /etc/sudoers.d/tramontana que escribiste en 05-02: aquí es donde las tres lecciones encajan. Y systemctl is-active --quiet en bucle evita el fallo clásico de comprobar la salud antes de que el proceso haya abierto el puerto.

• Olvidar daemon-reload. Editas la unidad, reinicias y no cambia nada: si has tocado un fichero de unidad, daemon-reload antes que nada. Y enable no arranca el servicio, solo crea el enlace: usa enable --now.
• Requires= sin After=. No garantiza ningún orden: las dos unidades arrancan en paralelo. Prefiere Wants= salvo que de verdad no puedas funcionar sin la otra. Y al migrar a un timer, comenta la línea de cron en el mismo cambio o tendrás dos ejecuciones simultáneas.
• Mandar el proceso al fondo con & o nohup en ExecStart. systemd lo pierde de vista y lo da por muerto: deja que corra en primer plano.
• Restart=always sin StartLimitBurst. Una aplicación que no arranca entra en un bucle que consume CPU y llena el disco de logs. Y no te rindas ante ProtectSystem=strict: el fallo te dice dónde escribe tu aplicación, así que añade la ruta a ReadWritePaths en lugar de quitar la protección.
• Editar la unidad de un paquete en /lib/systemd/system. La próxima actualización se lleva tu trabajo: drop-in en /etc/systemd/system/<unidad>.d/.
• Consejo: guarda tus unidades en git junto a los scripts. Una unidad es código de producción y se revisa como tal.

1. Diagnóstico de un servicio que no arranca. tramontana.service está en failed. Enumera, en orden, los cinco comandos que ejecutarías para averiguar la causa, y di qué te dice cada uno.
2. Un timer con recuperación. Escribe el par .service + .timer que ejecute /home/operador/scripts/purgar_releases.sh todos los lunes a las 05:10, que se recupere si el servidor estaba apagado, que no se solape con la copia y que quede registrado. Verifica la expresión de calendario.
3. Drop-in en lugar de edición. El proveedor pide que Tramontana arranque con TRAMONTANA_MAX_HILOS=8 y con 768 MiB de límite de memoria, sin modificar tramontana.service. Hazlo y demuestra que ha surtido efecto.

1.

El cuarto comando lanza la aplicación a mano con su usuario: ¿falla la app o la unidad?

Es el paso que más tiempo ahorra. Si a mano funciona y por systemd no, el culpable suele ser el endurecimiento —una ruta que falta en ReadWritePaths— o el entorno, porque la unidad no hereda tus variables.

2.

Conflicts= más After= garantizan que no coincidan, el registro es automático en el journal y no hace falta flock: systemd no relanza una unidad que ya está activa.

3. Con sudo systemctl edit tramontana.service, que crea el drop-in:

systemctl show da el valor efectivo (en bytes) y systemctl cat mostraría el drop-in al final de la unidad sin haber tocado el original. Y Environment= es acumulativa: la variable nueva se suma a las que ya definía la unidad.

srv-tramontana ya se gobierna solo. Sabes qué es un init y qué aporta systemd frente a SysV —arranque paralelo por dependencias, supervisión real, cgroups que no mienten, registro estructurado y aislamiento—; conoces los tipos de unidad y manejas systemctl de punta a punta: lees un status línea a línea, controlas con start/restart/reload, distingues enabled de active y disable de mask, sabes que enable es literalmente crear un enlace simbólico y que daemon-reload es obligatorio tras tocar cualquier fichero de unidad. Ajustas con drop-ins en lugar de editar unidades ajenas.

Escribes una unidad desde cero y entiendes las dos cosas donde todo el mundo tropieza: la diferencia entre orden (After/Before) y dependencia (Wants/Requires/BindsTo), y qué Type= corresponde a cada forma de arrancar. Endureces con NoNewPrivileges, ProtectSystem=strict y ReadWritePaths, lo compruebas con systemd-analyze security, pones techo con MemoryMax, CPUQuota y TasksMax vigilándolo con systemd-cgtop, manejas targets, analizas el arranque con blame y critical-chain y lanzas trabajos transitorios con systemd-run. Y las deudas están saldadas: tramontana.service existe, endurecido, con reinicio automático y límites, y arranca solo tras un reinicio del servidor; respaldo_tramontana.sh es ahora tramontana-respaldo.service disparado por un timer a las 04:20 con Persistent=true y RequiresMountsFor sobre el volumen de 05-04, con la línea de cron ya retirada; y desplegar.sh hace el systemctl restart que le faltaba, apoyándose en la regla de sudoers de 05-02. Falta la memoria del sistema. Tu servicio ya escribe en el journal, pero no sabes consultarlo; /var/log/tramontana/acceso.log lleva 412 líneas y creciendo sin que nadie lo rote, que fue la primera deuda que anuncié al cerrar el Módulo 4 y sigue sin pagar; y cuando Marta pregunte «¿qué pasó anoche a las 03:00?», ahora mismo no sabrías responder con precisión. En Registros del Sistema: journald y syslog verás las dos capas de registro que conviven en Ubuntu, exprimirás journalctl con todos sus filtros, harás el journal persistente, escribirás un /etc/logrotate.d/tramontana correcto y probado en simulación, conectarás lib/comunes.sh con el journal mediante logger, y aprenderás qué nunca debe acabar escrito en un log.