Ya tienes informe-diario.sh programado a las 06:30 y estado-servicio.sh cada 10 minutos. Esta lección no es cron otra vez: es la otra mitad del problema. Programar un script es fácil; lo difícil es que ese script esté escrito para ejecutarse sin nadie delante. Un script pensado para una persona en una terminal da por supuesto que alguien puede contestar una pregunta, ver un aviso en pantalla, pulsar Ctrl+C si se cuelga y relanzarlo si falla. A las 06:30 de la madrugada no hay nada de eso. Vamos a convertir «ejecutarse solo» en una lista de siete propiedades concretas y a implementarlas una a una hasta dejar informe-diario.sh verdaderamente desatendido.

1. Las siete propiedades de una tarea desatendida
2. No interactiva: nada que preguntar
3. Idempotente: ejecutarla dos veces no hace daño
4. Exclusiva: una sola a la vez
5. Observable: contar lo que ha hecho
6. Acotada y segura ante fallos
7. Configurable: --dry-run y --force
8. Notificar, no heredar el entorno y documentar
9. Aplicación: informe-diario.sh listo para producción

Cada propiedad responde a una pregunta que solo aparece cuando no hay nadie mirando:

Ninguna es opcional: a un script automático al que le falte una, tarde o temprano le ocurrirá el incidente que esa propiedad evitaba.

La regla es absoluta: un script automático no pregunta nada. Todo lo que un humano decidiría llega por una de tres vías: opciones de línea de comandos (03-05) para lo que cambia en cada ejecución, fichero de configuración (05-06) para lo estable de cada máquina, y variables de entorno para lo que inyecta quien lanza (cron, systemd, un contenedor). Y un read en automático no falla de forma limpia: se queda esperando. Si la entrada estándar está cerrada, devuelve error y con set -e el script muere con un mensaje incomprensible; si hay algo en ella, se lo come y sigue con un valor absurdo. La defensa activa es detectar que no hay terminal y negarse a preguntar:

[[ -t 0 ]] comprueba si el descriptor 0 está asociado a un terminal (05-05). Bajo cron no lo está, así que la función devuelve 1 con un mensaje claro en vez de colgarse. Compruébalo tú mismo: [[ -t 0 ]] && echo si || echo no responde si en tu terminal y no si lo ejecutas como echo | bash -c '…'. Su hermano [[ -t 1 ]] sirve para decidir si colorear la salida: con colores en un fichero de log acabas con \033[31m por todas partes.

Idempotente significa que ejecutar la operación una vez o cinco deja el sistema en el mismo estado. Es la propiedad que hace seguro un reintento, y en automatización los reintentos son constantes: cron se solapa, alguien relanza a mano tras un fallo, el cambio de hora duplica una ejecución (07-01), una tarea muere a la mitad.

Cuatro patrones resuelven casi todo. (a) Operaciones ya idempotentes por diseño: mkdir -p, rm -f, ln -sfn, install -d, rsync; prefiérelas siempre. (b) Comprobar antes de actuar, devolviendo 0, no error —«ya estaba hecho» es éxito, y un script que devuelve error por eso generará una alerta falsa cada noche—. (c) Escritura atómica: temporal más mv, el patrón más importante de los cuatro:

Escribir directamente sobre $destino lo deja a medias si el script muere, y otro proceso puede leer basura. Con temporal más mv, el destino o es el antiguo completo o es el nuevo completo, nunca un híbrido, porque rename(2) es atómico. La condición es que el temporal esté en el mismo sistema de ficheros; por eso el mktemp usa el directorio del destino y no /tmp. (d) Marcas de trabajo hecho para tareas caras: un fichero testigo ([[ -e $marca ]] && exit 0) que se crea solo al terminar con éxito.

Ya viste flock en 05-02 y su uso como envoltorio en el crontab (flock -n /var/lock/veloz.lock comando). La pregunta ahora es dónde ponerlo, y hay dos respuestas: en el crontab, que es una línea y no toca el script; o dentro del propio script, que protege se lance como se lance —desde cron, a mano, desde un timer o desde otro script—. Para una tarea importante, la segunda es la correcta:

Tres detalles que se escapan. exec 9> abre el descriptor 9 para toda la vida del script, y el candado se libera solo cuando el proceso termina: no hay que soltarlo ni en el trap. flock -n no espera (con flock -w 30 9 esperarías 30 segundos por si la anterior está acabando). Y aquí sale con exit 0, no con error, porque «ya hay una ejecución en marcha» es comportamiento normal, no una avería que merezca alerta. El fichero de candado va en /var/lock o /run/lock, nunca dentro del directorio de datos que la tarea manipula.

Si mañana no puedes responder «¿se ejecutó, cuánto tardó y qué hizo?» mirando un fichero, la tarea no es observable. Hacen falta tres cosas. Códigos de salida significativos, retomando la tabla de 05-03: 0 es todo bien —incluido «ya estaba hecho»—, 64 error de uso, 65 datos de entrada corruptos, 69 servicio no disponible, 75 fallo temporal y 78 error de configuración. Así quien llame decide sin leer el texto: 75 se reintenta con retroceso, 64 y 78 hay que arreglarlos a mano.

Mensajes con marca de tiempo y nivel, porque echo "empezando" no sirve en un log de tres meses:

date -Is da la marca ISO-8601 con zona horaria, que ordena bien alfabéticamente y no es ambigua. El diseño completo del registro —niveles, umbrales, componente, rotación— es el tema de 07-04. Y un resumen final legible: la última línea debe permitir juzgar la ejecución de un vistazo (FIN ok: 1284 envios, 37 incidencias, 12s, salida $destino).

Una tarea que se cuelga es peor que una que falla: no avisa, ocupa el candado, bloquea las siguientes y acumula procesos durante días. Todo lo que hable con el exterior necesita un límite de tiempo, y en dos niveles que se complementan: timeout 30s curl … dentro del script para cortar la operación concreta con un código tratable, y timeout 300s /ruta/script.sh desde el crontab como red de seguridad. timeout devuelve 124 cuando corta, y tu script debe distinguirlo de un fallo normal. Los reintentos, además, van limitados y con retroceso, retomando 05-03:

Tres cosas lo hacen correcto: hay un máximo de intentos (un while true reintentando eternamente es otra forma de colgarse), la espera se duplica para no machacar un servicio que ya sufre, y el último fallo devuelve 75 (EX_TEMPFAIL), que le dice al llamante «esto puede ser transitorio».

La cabecera del Módulo 5 sigue siendo la base —set -euo pipefail— y la limpieza garantizada con trap importa aquí el doble: nadie va a borrar a mano el temporal de 400 MB que quedó huérfano.

Lo que separa un script automático maduro de uno frágil es distinguir el error recuperable del fatal. Fatal: falta el CSV de envíos, no existe el directorio de salida, falta jq → registrar, salir con código y no continuar. Recuperable: una línea del CSV mal formada, la API no contesta a /metricas → registrar como WARN, contarlo, continuar y reflejarlo en el resumen. Como set -e aborta ante cualquier fallo, los recuperables hay que declararlos, y el if ! es la forma de hacerlo (05-03). Un script que aborta por no poder leer una métrica opcional es tan malo como uno que sigue adelante con el CSV corrupto: la decisión es tuya, orden por orden.

Una tarea que borra, mueve o publica cosas debe poder ejecutarse en falso. --dry-run permite estrenar una tarea, verificar un cambio de configuración o entender qué haría hoy, sin consecuencias. La implementación limpia no es llenar el código de if, sino un prefijo:

En modo normal EJECUTA está vacío y la expansión desaparece por completo, así que se ejecuta mv … tal cual. En simulación se expande a echo "[SIMULACION]" mv …, que imprime la orden ([SIMULACION] mv -f /tmp/informe.a3Kx9 /srv/veloz/informes/informe-2026-08-02.txt) en lugar de ejecutarla. Es el idioma de array de 04-03, y la regla es: solo las órdenes con efecto llevan el prefijo; leer, contar y calcular se hacen igual en los dos modos, para que la simulación sea realista. --force es el complemento: salta comprobaciones y confirmaciones, y es lo que da salida a la función confirma del apartado 2 —sin terminal y sin --force se niega; con --force sigue, nunca al revés—.

Notificar. Nadie lee logs que no fallan. Para que un fallo llegue a un humano hay tres vías: correo (salida no vacía más MAILTO en cron, 07-01), logger hacia el syslog (logger -t veloz-informe -p user.err "…"), y un fichero de estado que otro sistema lee, que es el más versátil y encaja con 06-05:

Ese fichero convierte «la tarea funcionó» en un dato consultable: el vigilante de 07-04 puede avisar si la última ejecución correcta tiene más de 26 horas. Es la única forma de detectar una tarea que no se ejecutó, algo que un log jamás dirá porque no hay línea que escribir cuando nada ocurre. No heredar el entorno. Ya viste en 07-01 que cron da un PATH mínimo; la conclusión de diseño va más allá: un script automático no debe confiar en lo que hereda, venga de cron, de systemd o de un ssh remoto (07-06). Se protege en cuatro líneas al principio:

Fijar el PATH en el script y no en el crontab tiene una ventaja: la garantía viaja con él y funciona igual desde un timer o desde SSH.

Documentar. Cuando la tarea falle serán las 3 de la mañana y quien mire no serás tú. El runbook mínimo son cuatro respuestas en la cabecera del script, y cuesta cinco minutos escribirlo:

El esqueleto de automatización completo; la lógica de awk y jq ya la tienes del Módulo 6:

Recorre el listado buscando las siete: no interactiva (todo por opciones y configuración, ningún read), idempotente (mkdir -p, la comprobación de $destino que devuelve 0, temporal más mv atómico), exclusiva (candado con descriptor 9), observable (INICIO y FIN, códigos 64/65, resumen JSON), acotada (timeout 20s en la API), segura ante fallos (set -euo pipefail, trap, CSV ilegible fatal frente a métricas ausentes recuperables) y configurable (--dry-run, --force, --fecha).

La línea de crontab final es más corta que la de 07-01, porque el script ya se protege solo, y ahora es posible probar antes de instalar con ~/veloz-ops/bin/informe-diario.sh --dry-run --fecha 2026-08-02:

• Dejar un read «solo por si acaso». En automático cuelga el proceso o devuelve basura. Todo por opciones, configuración o entorno.
• Confundir «ya estaba hecho» con error. Devolver código distinto de 0 genera una alerta falsa cada noche y la gente deja de mirarlas.
• Escribir directamente sobre el fichero final, o poner el temporal en /tmp. Lo primero deja el destino corrupto si falla a la mitad; lo segundo hace que el mv deje de ser atómico, porque copia y borra entre discos distintos.
• flock sin -n en una tarea periódica. Las ejecuciones se acumulan esperando en lugar de descartarse.
• Reintentar sin límite ni retroceso, o llamar sin timeout. Las dos son formas de colgarse eternamente, y la primera además machaca al servicio que ya está caído.
• --dry-run que no simula del todo, o colores en el log. Si una orden con efecto se cuela sin el prefijo la simulación miente; y sin decidir el color con [[ -t 1 ]] acabarás con secuencias de escape en un fichero de tres meses.
• Consejo: antes de programar una tarea nueva, ejecútala tres veces seguidas a mano. Si la segunda y la tercera no son inofensivas, todavía no es idempotente y no está lista para cron.

Ejercicio 1. Este fragmento pretende publicar el resumen del día. Señala los tres problemas que impiden ejecutarlo desatendido y reescríbelo.

Ejercicio 2. Escribe una función veloz_escribe_atomico para lib/comun.sh que reciba la ruta de destino, lea el contenido de la entrada estándar y lo publique de forma atómica, respetando el modo simulación mediante la variable SIMULAR.

Solución 1. Los tres problemas: (a) el read cuelga el script sin terminal; (b) mkdir sin -p falla en la segunda ejecución y curl sin -sSf ni tiempos de espera puede colgarse o guardar una página de error como si fuera JSON; (c) se escribe directamente en el destino, así que un fallo a la mitad deja un JSON truncado. Además, la variable sin comillas rompería con cualquier valor con espacios (03-06).

La fecha llega ahora como argumento con un valor por defecto sensato (${1:-…} de 03-06), se valida con =~ (05-04), y el trap garantiza que no queden temporales aunque el curl falle.

Solución 2.

El mktemp se crea junto al destino ("$destino.XXXXXX") y no en /tmp, que es la condición para que el mv sea un renombrado atómico y no una copia entre discos. En modo simulación consume igualmente la entrada con wc -c para no romper la tubería que la alimenta: si no leyeras stdin, el proceso de la izquierda recibiría un SIGPIPE. Y ante cualquier fallo se borra el temporal, dejando el destino anterior intacto.

Un script listo para ejecutarse solo cumple siete propiedades. Es no interactiva: cero read, todo por opciones, configuración o entorno, y [[ -t 0 ]] para negarse a preguntar cuando no hay nadie. Es idempotente: mkdir -p, comprobar antes de actuar devolviendo 0 cuando ya estaba hecho, escribir a temporal y publicar con mv atómico, y marcas para lo caro. Es exclusiva: flock -n como envoltorio en el crontab y, mejor, con exec 9> dentro del script para que proteja se lance como se lance. Es observable: códigos que distinguen tipos de fallo, líneas con date -Is y nivel, y un resumen final que se entiende de un vistazo. Es acotada: timeout en dos niveles sobre todo lo que hable con el exterior, y reintentos con máximo y retroceso. Es segura ante fallos: set -euo pipefail, trap de limpieza y una decisión consciente, orden por orden, sobre qué error es fatal y cuál recuperable. Y es configurable: --dry-run con el prefijo "${EJECUTA[@]}" para probarla sin consecuencias, y --force para saltarse las confirmaciones que en automático no puede contestar nadie. Encima de eso, dos cosas que no son código: no heredar el entorno —fija PATH, LC_ALL y umask, y comprueba las herramientas al empezar— y escribir el runbook mínimo en la cabecera.

Con la técnica de tareas desatendidas en la mano, en 07-03 la aplicamos a la operación que más se agradece haber automatizado y peor se lleva improvisar: el respaldo. Verás qué respaldar y qué no, la regla 3-2-1, la diferencia entre copia completa, incremental y diferencial, rsync --link-dest para copias incrementales que se restauran como completas, políticas de retención, verificación con sha256sum —porque un respaldo no verificado no es un respaldo— y, sobre todo, la parte que casi nadie prueba hasta que la necesita: la restauración. Nace ~/veloz-ops/bin/respaldo.sh.