Ja tens informe-diari.sh programat a les 06:30 i estat-servei.sh cada 10 minuts. Aquesta lliçó no és cron una altra vegada: és l'altra meitat del problema. Programar un script és fàcil; el difícil és que aquell script estigui escrit per executar-se sense ningú al davant. Un script pensat per a una persona en un terminal dona per fet que algú pot contestar una pregunta, veure un avís a la pantalla, prémer Ctrl+C si es penja i tornar-lo a llançar si falla. A les 06:30 de la matinada no hi ha res d'això. Convertirem «executar-se sol» en una llista de set propietats concretes i les implementarem una a una fins a deixar informe-diari.sh veritablement desatès.

1. Les set propietats d'una tasca desatesa
2. No interactiva: res per preguntar
3. Idempotent: executar-la dues vegades no fa mal
4. Exclusiva: una de sola alhora
5. Observable: explicar què ha fet
6. Acotada i segura davant fallades
7. Configurable: --dry-run i --force
8. Notificar, no heretar l'entorn i documentar
9. Aplicació: informe-diari.sh a punt per a producció

Cada propietat respon a una pregunta que només apareix quan no hi ha ningú mirant:

Cap no és opcional: a un script automàtic al qual li falti una, tard o d'hora li passarà l'incident que aquella propietat evitava.

La regla és absoluta: un script automàtic no pregunta res. Tot el que un humà decidiria arriba per una de tres vies: opcions de línia d'ordres (03-05) per al que canvia a cada execució, fitxer de configuració (05-06) per al que és estable a cada màquina, i variables d'entorn per al que injecta qui el llança (cron, systemd, un contenidor). I un read en automàtic no falla de manera neta: es queda esperant. Si l'entrada estàndard està tancada, retorna error i amb set -e l'script mor amb un missatge incomprensible; si hi ha alguna cosa, se la menja i continua amb un valor absurd. La defensa activa és detectar que no hi ha terminal i negar-se a preguntar:

[[ -t 0 ]] comprova si el descriptor 0 està associat a un terminal (05-05). Sota cron no ho està, així que la funció retorna 1 amb un missatge clar en lloc de penjar-se. Comprova-ho tu mateix: [[ -t 0 ]] && echo si || echo no respon si al teu terminal i no si ho executes com echo | bash -c '…'. El seu germà [[ -t 1 ]] serveix per decidir si acolorir la sortida: amb colors en un fitxer de registre acabes amb \033[31m per tot arreu.

Idempotent significa que executar l'operació un cop o cinc deixa el sistema en el mateix estat. És la propietat que fa segur un reintent, i en automatització els reintents són constants: cron s'encavalca, algú torna a llançar a mà després d'una fallada, el canvi d'hora duplica una execució (07-01), una tasca mor a mitges.

Quatre patrons ho resolen gairebé tot. (a) Operacions ja idempotents per disseny: mkdir -p, rm -f, ln -sfn, install -d, rsync; prefereix-les sempre. (b) Comprovar abans d'actuar, retornant 0, no error —«ja estava fet» és èxit, i un script que retorna error per això generarà una alerta falsa cada nit—. (c) Escriptura atòmica: temporal més mv, el patró més important dels quatre:

Escriure directament sobre $desti el deixa a mitges si l'script mor, i un altre procés pot llegir escombraries. Amb temporal més mv, el destí o és l'antic complet o és el nou complet, mai un híbrid, perquè rename(2) és atòmic. La condició és que el temporal estigui al mateix sistema de fitxers; per això el mktemp fa servir el directori del destí i no /tmp. (d) Marques de feina feta per a tasques cares: un fitxer testimoni ([[ -e $marca ]] && exit 0) que es crea només en acabar amb èxit.

Ja vas veure flock a 05-02 i el seu ús com a embolcall al crontab (flock -n /var/lock/veloz.lock ordre). La pregunta ara és on posar-lo, i hi ha dues respostes: al crontab, que és una línia i no toca l'script; o dins del mateix script, que el protegeix es llanci com es llanci —des de cron, a mà, des d'un temporitzador o des d'un altre script—. Per a una tasca important, la segona és la correcta:

Tres detalls que s'escapen. exec 9> obre el descriptor 9 per a tota la vida de l'script, i el pany s'allibera sol quan el procés acaba: no cal deixar-lo anar ni al trap. flock -n no espera (amb flock -w 30 9 esperaries 30 segons per si l'anterior està acabant). I aquí surt amb exit 0, no amb error, perquè «ja hi ha una execució en marxa» és comportament normal, no una avaria que mereixi alerta. El fitxer de pany va a /var/lock o /run/lock, mai dins del directori de dades que la tasca manipula.

Si demà no pots respondre «s'ha executat, quant ha trigat i què ha fet?» mirant un fitxer, la tasca no és observable. Calen tres coses. Codis de sortida significatius, reprenent la taula de 05-03: 0 és tot bé —inclòs «ja estava fet»—, 64 error d'ús, 65 dades d'entrada corruptes, 69 servei no disponible, 75 fallada temporal i 78 error de configuració. Així qui hi crida decideix sense llegir el text: 75 es reintenta amb retrocés, 64 i 78 s'han d'arreglar a mà.

Missatges amb marca de temps i nivell, perquè echo "començant" no serveix en un registre de tres mesos:

date -Is dona la marca ISO-8601 amb zona horària, que ordena bé alfabèticament i no és ambigua. El disseny complet del registre —nivells, llindars, component, rotació— és el tema de 07-04. I un resum final llegible: l'última línia ha de permetre jutjar l'execució d'un cop d'ull (FI ok: 1284 enviaments, 37 incidencies, 12s, sortida $desti).

Una tasca que es penja és pitjor que una que falla: no avisa, ocupa el pany, bloqueja les següents i acumula processos durant dies. Tot el que parli amb l'exterior necessita un límit de temps, i en dos nivells que es complementen: timeout 30s curl … dins de l'script per tallar l'operació concreta amb un codi tractable, i timeout 300s /cami/script.sh des del crontab com a xarxa de seguretat. timeout retorna 124 quan talla, i el teu script ho ha de distingir d'una fallada normal. Els reintents, a més, van limitats i amb retrocés, reprenent 05-03:

Tres coses el fan correcte: hi ha un màxim d'intents (un while true reintentant eternament és una altra manera de penjar-se), l'espera es duplica per no castigar un servei que ja pateix, i l'última fallada retorna 75 (EX_TEMPFAIL), que li diu a qui crida «això pot ser transitori».

La capçalera del Mòdul 5 segueix sent la base —set -euo pipefail— i la neteja garantida amb trap importa aquí el doble: ningú no esborrarà a mà el temporal de 400 MB que ha quedat orfe.

El que separa un script automàtic madur d'un de fràgil és distingir l'error recuperable del fatal. Fatal: falta el CSV d'enviaments, no existeix el directori de sortida, falta jq → registrar, sortir amb codi i no continuar. Recuperable: una línia del CSV mal formada, l'API no contesta a /metricas → registrar com a WARN, comptar-ho, continuar i reflectir-ho al resum. Com que set -e avorta davant de qualsevol fallada, els recuperables s'han de declarar, i l'if ! és la manera de fer-ho (05-03). Un script que avorta per no poder llegir una mètrica opcional és tan dolent com un que tira endavant amb el CSV corrupte: la decisió és teva, ordre per ordre.

Una tasca que esborra, mou o publica coses ha de poder executar-se en fals. --dry-run permet estrenar una tasca, verificar un canvi de configuració o entendre què faria avui, sense conseqüències. La implementació neta no és omplir el codi d'if, sinó un prefix:

En mode normal EXECUTA és buit i l'expansió desapareix per complet, així que s'executa mv … tal qual. En simulació s'expandeix a echo "[SIMULACIO]" mv …, que imprimeix l'ordre ([SIMULACIO] mv -f /tmp/informe.a3Kx9 /srv/veloz/informes/informe-2026-08-02.txt) en lloc d'executar-la. És l'idioma d'array de 04-03, i la regla és: només les ordres amb efecte porten el prefix; llegir, comptar i calcular es fan igual en tots dos modes, perquè la simulació sigui realista. --force n'és el complement: salta comprovacions i confirmacions, i és el que dona sortida a la funció confirma de l'apartat 2 —sense terminal i sense --force es nega; amb --force continua, mai al revés—.

Notificar. Ningú no llegeix registres que no fallen. Perquè una fallada arribi a un humà hi ha tres vies: correu (sortida no buida més MAILTO a cron, 07-01), logger cap al syslog (logger -t veloz-informe -p user.err "…"), i un fitxer d'estat que un altre sistema llegeix, que és el més versàtil i encaixa amb 06-05:

Aquell fitxer converteix «la tasca ha funcionat» en una dada consultable: el vigilant de 07-04 pot avisar si l'última execució correcta té més de 26 hores. És l'única manera de detectar una tasca que no s'ha executat, cosa que un registre no dirà mai perquè no hi ha cap línia per escriure quan no passa res. No heretar l'entorn. Ja vas veure a 07-01 que cron dona un PATH mínim; la conclusió de disseny va més enllà: un script automàtic no ha de confiar en el que hereta, vingui de cron, de systemd o d'un ssh remot (07-06). Es protegeix en quatre línies al principi:

Fixar el PATH a l'script i no al crontab té un avantatge: la garantia hi viatja i funciona igual des d'un temporitzador o des de SSH.

Documentar. Quan la tasca falli seran les 3 de la matinada i qui hi miri no seràs tu. El runbook mínim són quatre respostes a la capçalera de l'script, i costa cinc minuts escriure'l:

L'esquelet d'automatització complet; la lògica d'awk i jq ja la tens del Mòdul 6:

Recorre el llistat buscant-hi les set: no interactiva (tot per opcions i configuració, cap read), idempotent (mkdir -p, la comprovació de $desti que retorna 0, temporal més mv atòmic), exclusiva (pany amb descriptor 9), observable (INICI i FI, codis 64/65, resum JSON), acotada (timeout 20s a l'API), segura davant fallades (set -euo pipefail, trap, CSV illegible fatal enfront de mètriques absents recuperables) i configurable (--dry-run, --force, --data).

La línia de crontab final és més curta que la de 07-01, perquè l'script ja es protegeix sol, i ara és possible provar abans d'instal·lar amb ~/veloz-ops/bin/informe-diari.sh --dry-run --data 2026-08-02:

• Deixar un read «només per si de cas». En automàtic penja el procés o retorna escombraries. Tot per opcions, configuració o entorn.
• Confondre «ja estava fet» amb error. Retornar un codi diferent de 0 genera una alerta falsa cada nit i la gent deixa de mirar-les.
• Escriure directament sobre el fitxer final, o posar el temporal a /tmp. El primer deixa el destí corrupte si falla a mitges; el segon fa que el mv deixi de ser atòmic, perquè copia i esborra entre discos diferents.
• flock sense -n en una tasca periòdica. Les execucions s'acumulen esperant en lloc de descartar-se.
• Reintentar sense límit ni retrocés, o cridar sense timeout. Totes dues són maneres de penjar-se eternament, i la primera a més castiga el servei que ja està caigut.
• --dry-run que no simula del tot, o colors al registre. Si una ordre amb efecte s'hi cola sense el prefix la simulació menteix; i sense decidir el color amb [[ -t 1 ]] acabaràs amb seqüències d'escapada en un fitxer de tres mesos.
• Consell: abans de programar una tasca nova, executa-la tres vegades seguides a mà. Si la segona i la tercera no són inofensives, encara no és idempotent i no està a punt per a cron.

Exercici 1. Aquest fragment pretén publicar el resum del dia. Assenyala els tres problemes que impedeixen executar-lo desatès i reescriu-lo.

Exercici 2. Escriu una funció veloz_escriu_atomic per a lib/comu.sh que rebi el camí de destí, llegeixi el contingut de l'entrada estàndard i el publiqui de manera atòmica, respectant el mode simulació mitjançant la variable SIMULAR.

Solució 1. Els tres problemes: (a) el read penja l'script sense terminal; (b) mkdir sense -p falla a la segona execució i curl sense -sSf ni temps d'espera es pot penjar o desar una pàgina d'error com si fos JSON; (c) s'escriu directament al destí, així que una fallada a mitges deixa un JSON truncat. A més, la variable sense cometes es trencaria amb qualsevol valor amb espais (03-06).

La data arriba ara com a argument amb un valor per defecte assenyat (${1:-…} de 03-06), es valida amb =~ (05-04), i el trap garanteix que no quedin temporals encara que el curl falli.

Solució 2.

El mktemp es crea al costat del destí ("$desti.XXXXXX") i no a /tmp, que és la condició perquè el mv sigui un reanomenat atòmic i no una còpia entre discos. En mode simulació consumeix igualment l'entrada amb wc -c per no trencar la canonada que l'alimenta: si no llegissis stdin, el procés de l'esquerra rebria un SIGPIPE. I davant de qualsevol fallada s'esborra el temporal, deixant el destí anterior intacte.

Un script a punt per executar-se sol compleix set propietats. És no interactiva: zero read, tot per opcions, configuració o entorn, i [[ -t 0 ]] per negar-se a preguntar quan no hi ha ningú. És idempotent: mkdir -p, comprovar abans d'actuar retornant 0 quan ja estava fet, escriure a temporal i publicar amb mv atòmic, i marques per al que és car. És exclusiva: flock -n com a embolcall al crontab i, millor, amb exec 9> dins de l'script perquè el protegeixi es llanci com es llanci. És observable: codis que distingeixen tipus de fallada, línies amb date -Is i nivell, i un resum final que s'entén d'un cop d'ull. És acotada: timeout en dos nivells sobre tot el que parli amb l'exterior, i reintents amb màxim i retrocés. És segura davant fallades: set -euo pipefail, trap de neteja i una decisió conscient, ordre per ordre, sobre quin error és fatal i quin recuperable. I és configurable: --dry-run amb el prefix "${EXECUTA[@]}" per provar-la sense conseqüències, i --force per saltar-se les confirmacions que en automàtic no pot contestar ningú. A sobre d'això, dues coses que no són codi: no heretar l'entorn —fixa PATH, LC_ALL i umask, i comprova les eines en començar— i escriure el runbook mínim a la capçalera.

Amb la tècnica de tasques desateses a la mà, a 07-03 l'apliquem a l'operació que més s'agraeix haver automatitzat i pitjor es porta improvisar: la còpia de seguretat. Veuràs què s'ha de copiar i què no, la regla 3-2-1, la diferència entre còpia completa, incremental i diferencial, rsync --link-dest per a còpies incrementals que es restauren com a completes, polítiques de retenció, verificació amb sha256sum —perquè una còpia no verificada no és una còpia— i, sobretot, la part que gairebé ningú no prova fins que la necessita: la restauració. Neix ~/veloz-ops/bin/copia.sh.