Són les 03:12. El telèfon vibra: «L'API de Meteora respon lenta. Clients queixant-se des de fa uns minuts.» No hi ha més informació, ningú no sap què ha canviat i la persona que va escriure l'agregador és de vacances. Tens accés per SSH a meteo-01 i la resta depèn de tu.

Aquesta lliçó és diferent de totes les anteriors. No introdueix conceptes nous: fa servir tots els que has après. Recorreràs un incident complet, amb les sortides reals de cada ordre, les hipòtesis que es descarten, les dues que resulten certes i una tercera que apareix sense buscar-la i que canvia del tot la naturalesa del problema. Veuràs com la teoria del mòdul 2 sobre patrons d'accés al disc es converteix en una línia d'iostat, com la jerarquia de bloqueigs del mòdul 3 es converteix en un fil penjat a /proc/<pid>/stack, i com el mòdul 5 obliga a aturar la investigació de rendiment en sec.

Al final tancarem el curs: un mapa del que hem recorregut, els camins que s'obren i com continuar practicant.

1. El guió d'actuació
2. Primera fase: els 60 segons inicials
3. Segona troballa: l'agregador i el patró d'accés
4. Mitigació davant de solució de fons
5. Tercera troballa: fils en estat D que no avancen
6. L'interbloqueig, la seva correcció i la prova
7. Quarta troballa, inesperada: l'incident canvia de naturalesa
8. Post mortem sense culpables
9. Exercicis finals
10. Tancament del curs

Abans d'escriure una sola ordre, tres decisions. Costen trenta segons i canvien el resultat de l'incident.

Primera: acotar el símptoma amb dades, no amb impressions. «Va lenta» no permet comprovar si alguna cosa millora. Necessites un número i un instant.

Compara-ho amb la línia base d'un dimarts normal (p50=0.031 p95=0.104 p99=0.198) i ja tens el símptoma quantificat: el p99 s'ha multiplicat per 30. Repetint la consulta minut a minut, la degradació comença entre les 03:04 i les 03:06. Aquest instant és la teva àncora: tot el que investiguis es correlaciona amb ell.

Segona: decidir si mitigues o investigues primer. Són objectius en tensió. Mitigar restaura el servei però destrueix evidències: si reinicies meteo-api, l'estat que explica l'errada desapareix. Investigar preserva les proves però allarga la caiguda. El criteri és l'impacte:

A les 03:12 l'API respon, amb una latència dolenta però sense errors massius. Decideixes investigar, amb un límit de temps explícit: quinze minuts.

Tercera: anotar-ho tot amb marca de temps. Obre un quadern de l'incident i desa-hi cada sortida:

Per què això importa tant. D'aquí a tres hores no recordaràs si l'aqu-sz era 18 o 27, i el post mortem depèn d'aquests números. A més, si l'incident acaba sent de seguretat —com passarà—, la bitàcola es converteix en part de la cadena de custòdia de 05-04.

Executes la llista de 07-03 sencera, per ordre, sense saltar-te'n res.

Què descarta. Res encara, però orienta: 28 de càrrega en una màquina de 8 nuclis, amb la mitjana d'1 minut molt per damunt de la de 15. El problema és recent i està creixent. No hi va haver reinici (41 dies d'uptime), així que descartem una arrencada fallida.

Què descarta. No hi ha morts per OOM, no hi ha errors de dispositiu, no hi ha RAID degradat, no hi ha segfault. Això elimina de cop les tres causes catastròfiques més freqüents. La línia de recovery done a les 02:41 és d'una resincronització del RAID ja acabada: hauria pogut ser la causa, però va acabar 24 minuts abans del símptoma. Anotada com a no descartada del tot, perquè tota coincidència temporal mereix revisió.

Aquí hi ha la primera troballa gran. r=1 (un sol procés llest per executar) davant de b=31 (trenta-un processos bloquejats en E/S ininterrompible). si/so a zero: no és memòria. us+sy al voltant del 6 % amb wa al 89 %: no és CPU. La càrrega de 28 s'explica íntegrament pels processos en estat D de 02-01, que a Linux —i només a Linux— compten a la càrrega mitjana.

Què descarta. El %iowait està repartit per igual entre els vuit nuclis, així que no és un nucli saturat ni una interrupció mal distribuïda (02-07). I %steal a zero descarta l'hipervisor (06-01): ningú no ens està robant CPU.

Què descarten. Un disponible de 6,1 GB i una pressió de memòria zero: la memòria queda definitivament fora. Les connexions establertes són al rang normal. I PSI és concloent: un io full avg10 del 71,6 % significa que en els últims deu segons la màquina n'ha passat set de cada deu sense poder progressar per esperar el disc, mentre que la pressió de CPU és residual.

Conclusió de la primera fase, a les 03:17: el coll d'ampolla és l'E/S de disc. N'hi ha hagut prou amb tres minuts i s'han descartat amb dades la CPU, la memòria, l'intercanvi, la xarxa, l'hipervisor i una errada de maquinari. Anota-ho i continua.

Lectura completa d'aquesta sortida, que és el cor del diagnòstic. L'amplada de banda és ridícula: 16 MB/s, una cosa que qualsevol disc de fa vint anys donaria sense despentinar-se. Però són 4.102 operacions per segon, i rareq-sz està clavat a 4,00 KB: peticions de la mida mínima. rrqm/s és zero, és a dir, el planificador d'E/S (02-05) no pot fusionar res, cosa que només passa quan els blocs demanats no són contigus. És la signatura exacta de la lectura aleatòria.

Un RAID 1 de dos discos mecànics dona de l'ordre de 150-200 IOPS aleatòries per disc, unes 300-400 en lectura sumant-los tots dos perquè el mirall reparteix les lectures. N'estem demanant més de deu vegades aquesta capacitat. D'aquí l'aqu-sz=27,4 —vint-i-set peticions esperant de mitjana, la saturació d'USE— i el r_await=52 ms. El %util del 99,9 % és cert però poc informatiu: el que fa mal és la cua.

Qui ho provoca?

Què demostra. L'agregador està llegint gairebé 16 MB/s —el total del dispositiu— i acumula un iodelay enorme: és ell qui satura el disc. meteo-api tot just llegeix, però el seu iodelay de 41 indica que també està esperant, i aquesta espera és la latència que pateix l'usuari. Tenim culpable i víctima.

Va arrencar a les 03:00:14 pel seu temporitzador i porta 17 minuts corrent, quan normalment en triga dos. Encaixa perfectament amb l'inici del símptoma a les 03:05.

La troballa definitiva. El fitxer d'un dia ocupa 17.280.000 bytes, uns 16,5 MiB, i hauria de cabre en uns pocs extents contigus. En té 5.314. I read_bytes diu que l'agregador ha llegit 17,9 GB del disc per processar un fitxer de 16,5 MB: està rellegint el mateix fitxer més de mil vegades, o accedint-hi de manera completament desordenada.

Per què el patró d'accés importa tant, que és la teoria de 02-05 i 04-05 feta carn. En un disc mecànic, una lectura seqüencial de 16,5 MB és un sol posicionament del capçal seguit d'una transferència contínua: uns 0,15 segons. Els mateixos 16,5 MB llegits com a 4.200 peticions aleatòries de 4 KB són 4.200 posicionaments d'uns 10 ms cadascun: 42 segons, gairebé tres-centes vegades més, amb exactament els mateixos bytes llegits. El disc no és lent; el patró és dolent. I la fragmentació en 5.314 extents converteix fins i tot una lectura «seqüencial» del fitxer en una cosa semblant a l'accés aleatori, perquè els blocs lògicament contigus estan físicament dispersos: és la conseqüència que l'ingestor hagi anat afegint al fitxer durant 24 hores mentre el sistema de fitxers assignava espai on podia.

Són les 03:24 i cal restaurar el servei. Distingeix sempre les dues coses.

Mitigació immediata (minuts, reversible, no arregla la causa):

Què fa i per què funciona. ionice -c 3 mou el procés a la classe idle del planificador d'E/S: les seves peticions només s'atenen quan no n'hi ha cap altra de pendent. meteo-api deixa de competir en igualtat de condicions i la seva latència ha de caure immediatament.

Verifica, sempre, que la mitigació funciona:

Resultat parcial. r_await baixa de 52 a 11 ms, aqu-sz de 27 a 6, i el p99 de l'API passa de 6,1 s a 0,94 s. Millora enorme… però la línia base era 0,198 s. Continua havent-hi alguna cosa malament, i aquest residu és el que portarà a la tercera troballa. Anotar-ho és fonamental: el parany clàssic de l'incident és donar per tancat el cas tan bon punt millora prou.

Mitigació duradora, aplicant els cgroups de 06-02 des de la unitat, perquè no depengui que algú executi ionice a mà:

Què aconsegueix. IOSchedulingClass=idle fa permanent el que feia l'ionice; IOWeight=10 davant de l'IOWeight=200 de meteo-api reparteix vint a un quan tots dos competeixen; i IOReadBandwidthMax posa un sostre dur traduït a io.max al cgroup del servei. És el mateix mecanisme del nucli que limita un contenidor, aplicat a un servei natiu. Nota important: MemoryMax=1G acota a més el dany d'una eventual fuita, matant només l'agregador en lloc de deixar que l'OOM killer triï víctima (02-04).

Solució de fons, que no es fa a les tres de la matinada però s'anota com a acció del post mortem:

Són les 03:31. El disc ja no està saturat, però el p99 continua a 0,94 s, gairebé cinc vegades la línia base. Tornes a mirar meteo-api.

Què revela. ps -eLo llista fils (-L), no processos: sense aquesta opció no veuries res de tot això (03-02). Tres fils són en estat D i el camp wchan —la funció del nucli on dormen— diu exactament què esperen: flock_lock_inode_wait, és a dir, un bloqueig de fitxer de 04-04. I dos més són a futex_wait_queue, esperant un mutex d'espai d'usuari (03-04).

Confirmació des del nucli. La pila del fil dins del nucli confirma que és dins de la crida flock() i no en un altre lloc. És la mateixa tècnica que vas aprendre a 03-06 per diagnosticar un procés encallat en D.

El quadre complet. /proc/locks és la taula de bloqueigs del nucli, i aquí hi ha dos protagonistes: el PID 1834 (meteo-api) té pres el bloqueig de la memòria cau (cache.lock), i el PID 9127 (agregador) té pres el del fitxer de dades. Cadascun espera el que té l'altre.

I aquí hi ha la causa arrel. La pila d'usuari delata l'ordre real d'adquisició: refrescar_cache_des_de_disc() pren primer el bloqueig de la memòria cau i després demana el del fitxer. Però la jerarquia acordada a 03-06 per a tot el sistema és:

configuració → memòria cau → fitxer → registre

Un moment: aquest codi respecta la jerarquia (memòria cau abans que fitxer). Qui la viola és l'altre extrem. Mirant l'agregador:

Confirmat: interbloqueig per violació de la jerarquia. L'agregador va prendre primer el bloqueig del fitxer i ara demana el de la memòria cau; meteo-api va prendre el de la memòria cau i demana el del fitxer. És el cicle d'espera circular, la quarta condició de Coffman, en la seva forma més pura i amb només dos participants. gdb -batch amb -ex 'thread apply all bt' no és destructiu si es fa servir amb cura, però atura el procés mentre s'executa: fes-lo servir breument i sabent que hi afegeixes latència.

Nota important sobre per què no s'havia vist abans: amb l'agregador acabant en dos minuts, la finestra d'encavalcament era mínima. En allargar-se a 17 minuts per la saturació de disc, la probabilitat de coincidència es va disparar. El primer problema en va destapar un segon, que portava mesos latent. És un patró habitual: els interbloqueigs rars es tornen freqüents quan alguna cosa alenteix el sistema.

Mitigació immediata, perquè el cicle no es trenca sol:

Per què matar l'agregador i no meteo-api. És la recuperació per terminació de 03-06, triant la víctima amb dos criteris: l'agregador és reexecutable —el seu temporitzador el tornarà a llançar, i amb Persistent=true no es perd l'execució— mentre que reiniciar meteo-api tallaria 1.188 connexions establertes. A més, SIGTERM en lloc de SIGKILL li dona l'oportunitat de tancar netament, evitant exactament els fitxers truncats que detectaria la comprovació mida % 24 != 0 de 07-01.

Servei restaurat a les 03:44: p99 de 0,204 s, indistingible de la línia base de 0,198 s. I ara, la correcció de fons, que és de codi:

I la prova que ja no passa, que és la part que gairebé tothom es salta:

Per què així. La primera prova reprodueix l'escenari que en producció era rar; si l'interbloqueig persistís, apareixeria en uns pocs intents. La segona és una comprovació contínua barata que es pot convertir en mètrica. La tercera és la més valuosa a llarg termini: centralitzar tota adquisició de bloqueigs en un únic mòdul que els prengui sempre en l'ordre de la jerarquia converteix la disciplina en una cosa que el compilador i una regla de revisió poden vigilar, en lloc de dependre que cada programador recordi l'acord. És la prevenció de 03-06 portada a la pràctica.

Són les 03:52. El servei està bé i estàs reunint material per al post mortem. Revises si l'agregador va deixar restes:

T'atures. Aquest fitxer té el bit setuid (rws), pertany a root, té nom ocult i data de les 02:51. Res del sistema de Meteora no crea això. I llavors comproves l'altra cosa que t'havia estranyat:

Hi ha un buit d'onze minuts (02:47-02:58) en un registre que escriu milers de línies per minut. Un servei que estigués bloquejat deixaria menys línies, no cap. Un buit exacte i net en un fitxer de registre és, fins que es demostri el contrari, manipulació.

Aquí l'incident deixa de ser de rendiment. Dos indicadors independents —un binari setuid de root aparegut a les 02:51 a /tmp i un buit als registres que l'envolta— apunten a un possible compromís. A partir d'aquest punt, tot el que has après al mòdul 7 se subordina al que has après al mòdul 5.

El primer és el que NO es fa:

• No executis el binari, ni tan sols amb --help o en una màquina «de proves». És setuid de root.
• No l'esborris. És la prova principal.
• No reiniciïs la màquina. Perdries tota la memòria, les connexions i els processos, que és justament el més valuós.
• No continuïs «investigant el rendiment». Cada ordre que executes modifica temps d'accés, entrades del diari i historial de shell, i contamina l'escena.
• No avisis pel canal que podria estar compromès. Si l'atacant hi té accés, llegirà els teus missatges.

Preservar per ordre de volatilitat (05-04), del més efímer al més durador:

Què aporta cadascun. stat dona els tres temps de l'inode sense obrir el fitxer. El hash SHA-256 permet demostrar després que l'evidència no es va alterar: és el fonament tècnic de la cadena de custòdia. last -F mostra els inicis de sessió amb data completa. ausearch consulta auditd —si estava actiu, i per això s'instal·la abans de necessitar-lo— per les execucions d'aquella finestra. I el find busca altres fitxers setuid recents a tot el sistema, perquè un atacant rarament en deixa només un.

Contenir sense destruir, en aquest ordre:

1. Aïllar la xarxa mantenint la màquina engegada: regles nftables que només permetin el teu accés d'administració. Apagar-la destrueix la memòria; desconnectar-la del tot també pot alertar l'atacant.
2. No canviar credencials encara si això avisés l'intrús, llevat d'indicació de qui coordini la resposta.
3. Escalar immediatament: responsable de seguretat, propietari del servei, direcció, i assessoria jurídica i de compliment. Si hi va haver accés a dades personals, a la UE el RGPD marca terminis de notificació de 72 hores que comencen a córrer des del coneixement del fet, i aquesta decisió no la pren qui és a la consola a les quatre del matí.
4. Canviar a un canal de comunicació fora de banda i documentar qui sap què i des de quan.

Advertència expressa. Aquest relat és material didàctic. Una resposta a incidents real ha de seguir el procediment formal de la teva organització i comptar amb assessorament legal. Les decisions sobre preservació de proves, notificació a autoritats i clients, comunicació pública i eventual denúncia tenen conseqüències jurídiques i contractuals que excedeixen el que és tècnic. Si la teva organització no té aquest procediment escrit, redactar-lo abans del pròxim incident és més valuós que qualsevol eina.

I per què s'atura aquí la investigació de rendiment. Per tres raons sòlides. Primera, contaminació d'evidències: cada ordre altera l'escena i pot inutilitzar l'anàlisi forense. Segona, canvi de prioritat: una latència alta costa diners, un compromís pot costar les dades de milers de persones. I tercera, canvi d'hipòtesi: si hi ha un intrús, tot el que has diagnosticat es torna sospitós —l'agregador es va alentir sol, o algú el va forçar?, el buit del registre tapa el moment en què es va col·locar el binari?—. No saps si el rendiment va ser la causa, la conseqüència o la cortina de fum. Investigar rendiment sobre un sistema possiblement compromès és construir sobre sorra.

Un post mortem sense culpables (blameless) parteix d'una premissa demostrada: les persones actuen raonablement amb la informació que tenen en aquell moment. Si l'objectiu és assenyalar algú, la gent amaga informació i la mateixa errada torna a passar. Si l'objectiu és entendre el sistema, s'aprèn.

Cronologia (totes les hores en CEST del 31/08/2026):

Causa arrel davant de causes contribuents. La distinció no és acadèmica: determina en què s'inverteix l'esforç.

• Causa arrel de la degradació: l'agregador llegeix les dades amb un patró aleatori de 4 KB —rellegint 17,9 GB per processar 16,5 MB— sobre fitxers fragmentats en més de 5.000 extents, cosa que excedeix en un ordre de magnitud la capacitat d'IOPS del RAID 1.
• Contribuent 1: no hi havia límits d'E/S a la unitat de l'agregador, així que podia consumir el 100 % del disc competint d'igual a igual amb el servei de cara a l'usuari.
• Contribuent 2: l'agregador viola la jerarquia de bloqueigs acordada. Latent durant mesos, es va manifestar en allargar-se la seva execució. No en va ser la causa, però sense ell el servei hauria tornat a la normalitat al minut 12 en lloc del 32.
• Contribuent 3: no hi havia alerta sobre pressió d'E/S. L'avís va arribar dels clients, no del sistema, amb set minuts de retard.
• Contribuent 4: /tmp estava muntat sense noexec ni nosuid, cosa que va permetre que un binari setuid fos executable allà.
• Contribuent 5: els registres només eren a la màquina, per la qual cosa el buit no es pot contrastar amb cap còpia externa.

Accions preventives concretes, cadascuna amb responsable i termini:

Fixa't en el patró: cap acció no és «anar amb més compte». Totes són canvis en el sistema —límits, alertes, muntatges, estructura de codi— que fan que l'errada sigui impossible o que es detecti sola. Aquest és el criteri per saber si un post mortem ha servit d'alguna cosa.

Consells finals per al torn de guàrdia: comença sempre per dmesg; quantifica abans de tocar i torna a mesurar després; posa un límit de temps a la fase d'investigació i respecta'l; avisa aviat encara que no tinguis la resposta, perquè la gent tolera molt millor la incertesa comunicada que el silenci; i desconfia de la primera explicació que encaixa, perquè els incidents reals, com aquest, solen tenir més d'una causa.

Cada nit entre les 02:00 i les 04:00, meteo-api deixa de respondre uns segons. systemctl status diu active (running) quan el mires al matí, però Main PID ha canviat. Dades recollides:

Diagnostica amb el mètode de 07-03: qui va causar el problema, per què va morir qui va morir, i quina mitigació i quina solució de fons aplicaries.

Després d'editar /etc/meteora/meteora.conf per afegir-hi un camí de memòria cau nou, meteo-api no arrenca:

Executat a mà com a meteora, el binari arrenca sense problemes. Explica la contradicció i dona la solució correcta, a més de dues d'incorrectes que cal evitar i per què.

Solució 1

Diagnòstic. Els indicadors són inequívocs i cap no és d'E/S: un disponible de només 402 MB, si=1.204 i so=1.890 pàgines per segon simultàniament —el sistema fica i treu pàgines alhora, que és la definició de thrashing (02-04)— i una pressió de memòria del 58 % (some) amb un 31 % de full: gairebé un terç del temps la màquina sencera no progressa.

Qui va causar el problema i qui va morir no són el mateix. La primera línia de dmesg ho diu literalment: agregador invoked oom-killer, és a dir, va ser la petició de memòria de l'agregador la que va esgotar el sistema i va disparar el mecanisme. Però el triat va ser meteo-api, amb 2,9 GB d'anon-rss. La raó és a l'oom_score, que és essencialment proporcional a la memòria resident: l'OOM killer mata el procés més gran, no el culpable. I com que meteo-api corre sota systemd amb Restart=on-failure, es reinicia sol, cosa que explica l'active (running) amb un Main PID diferent al matí i el fet que ningú no se n'assabentés.

La finestra 02:00-04:00 coincideix amb les execucions nocturnes de l'agregador; el mecanisme és una acumulació de memòria al procés d'agregació —probablement carrega a la RAM tot l'històric en lloc de processar-lo per blocs.

Mitigació (aquesta nit, sense tocar codi):

Amb això, quan l'agregador superi 1 GB, l'OOM killer del cgroup el matarà a ell i només a ell, sense tocar la resta del sistema; MemoryHigh hi afegeix un esglaó previ en què el nucli el frena i reclama pàgines agressivament abans d'arribar al límit dur. És exactament el mecanisme de 06-02. Convé a més protegir la víctima amb MemoryMin=512M a meteo-api.service, que reserva memòria que el nucli no li reclamarà.

Solució de fons: processar l'històric per blocs amb un consum acotat i constant, en lloc de carregar-lo sencer. I verificació: seguir el RSS de l'agregador durant una execució (while true; do awk '/VmRSS/{print $2}' /proc/$(pgrep -x agregador)/status; sleep 10; done) per comprovar que s'estabilitza en lloc de créixer linealment. Alerta preventiva: memory some avg60 > 20 % durant 5 minuts, que hauria avisat setmanes abans que el primer client.

El que no cal fer: abaixar vm.swappiness (no falta menys swap, falta memòria), afegir RAM sense entendre el creixement (només endarrereix el problema), ni ajustar l'oom_score_adj de meteo-api perquè no el triïn (mouries la mort a un altre procés innocent).

Solució 2

La contradicció és aparent i la seva explicació és l'enfortiment de la unitat. A mà, el binari corre amb el sistema de fitxers normal i meteora pot escriure allà on els seus permisos li deixin. Sota systemd, la unitat té ProtectSystem=strict, que munta tot l'arbre del sistema en només lectura dins de l'espai de noms de muntatge del servei, amb les úniques excepcions declarades a ReadWritePaths=: /var/lib/meteora, /var/log/meteora i /run/meteora. El camí nou, /var/cache/meteora, no és en aquesta llista, així que el procés veu un sistema de fitxers de només lectura i falla amb EROFS. És el mecanisme d'aïllament de 05-03 funcionant exactament com cal.

Solució correcta, que a més delega en systemd la creació del directori amb el propietari i el mode adequats:

CacheDirectory=meteora crea /var/cache/meteora amb propietari meteora:meteora, l'afegeix automàticament als camins escrivibles i el gestiona dins del cicle de vida del servei. L'alternativa acceptable, si el directori ja existeix i el gestiona un altre procés, és afegir ReadWritePaths=/var/cache/meteora.

Dues solucions incorrectes i per què:

1. Treure ProtectSystem=strict. Resol el símptoma desarmant la protecció: el servei passa a poder escriure a tot el sistema, inclosos /etc i /usr. Canvies un problema de configuració de cinc línies per un augment permanent de la superfície d'atac, justament al servei exposat a Internet. La puntuació de systemd-analyze security ho reflectiria immediatament.
2. Executar el servei com a root (o donar chmod 777 al directori). Llença per la borda tota la cadena de decisions del curs: el compte sense shell, l'UID 990, CAP_NET_BIND_SERVICE en lloc de root, NoNewPrivileges. I 777 permetria a qualsevol usuari del sistema —inclòs un procés compromès— manipular la memòria cau del servei.

Lliçó general: quan un servei funciona a mà i falla sota systemd, la diferència és gairebé sempre a l'entorn (PATH, directori de treball, variables) o a l'enfortiment (ProtectSystem, ReadWritePaths, SystemCallFilter, capabilities). I la resposta correcta és gairebé sempre declarar l'excepció concreta, mai desactivar la protecció.

Has resolt un incident complet, i en fer-ho has fet servir el curs sencer. Val la pena veure'n el mapa, perquè cada peça teòrica ha acabat convertida en una eina de diagnòstic.

Del mòdul 1 venia la idea que el sistema operatiu és una màquina estesa i un gestor de recursos, i que tot passa per crides al sistema; sense això, strace, wchan i /proc/<pid>/stack serien màgia. Del mòdul 2 van sortir els estats de procés —D i el seu pes a la càrrega mitjana—, els patrons d'accés al disc que expliquen per què 16,5 MB poden trigar 42 segons, l'OOM killer triant per mida i no per culpa, i RSS davant de VSZ per detectar una fuita. Del mòdul 3 van venir els fils, flock, el futex i, sobretot, la jerarquia de bloqueigs la violació de la qual va produir l'interbloqueig i la centralització de la qual el preveu. Del mòdul 4, els inodes i /proc/locks, la fragmentació en extents que filefrag va revelar, i l'escriptura atòmica que evita fitxers truncats. Del mòdul 5, tot el que va passar a partir de les 03:52: el binari setuid, el buit al registre, l'ordre de volatilitat, la cadena de custòdia, noexec a /tmp i l'obligació d'escalar. Del mòdul 6, els cgroups que van limitar l'agregador amb io.max i MemoryMax. I del mòdul 7, la shell que ho va executar tot, systemd que ho governa i el mètode que va ordenar la investigació.

Aquest és el missatge central del curs: la teoria no és un peatge previ a la pràctica, és el que permet interpretar el que veus. Dues persones executen iostat -x i veuen els mateixos números; només una sap que un rareq-sz de 4 KB amb rrqm/s a zero significa accés aleatori, que la cua importa més que la utilització i que un RAID 1 duplica lectures però no escriptures. La diferència no és a l'ordre, sinó als mòduls 2 i 4.

Els camins que s'obren des d'aquí:

Tots comparteixen la mateixa base: la que acabes d'acabar.

Com continuar practicant, que és l'única cosa que consolida tot això:

• Munta una màquina virtual de laboratori i trenca-la expressament. Provoca un OOM, satura el disc amb fio, crea un interbloqueig amb dos guions i flock, esborra un fitxer d'unitat i arregla'l. Res no ensenya tant com reparar una cosa que has trencat tu.
• Llegeix /proc amb curiositat. Cada fitxer de /proc/<pid>/ és una finestra a una estructura del nucli. Dedica una tarda a recórrer status, maps, io, limits, stack, fd/ i environ d'un procés real: n'entendràs més que amb molts capítols.
• Reprodueix els exercicis del curs a la teva pròpia màquina, canviant-ne els números. Els del mòdul 3 i els laboratoris de 07-03 són els que més rendeixen.
• Llegeix registres encara que no passi res. Familiaritzar-te amb l'aspecte d'un journalctl normal és el que et permetrà detectar l'anormal en tres segons.
• Escriu els teus propis post mortem, encara que l'incident sigui domèstic i tu l'únic lector. Posar per escrit la cronologia i la causa arrel és el que converteix una experiència en coneixement.

Vam començar definint el sistema operatiu com una màquina estesa que amaga la complexitat del maquinari. Acabem a les quatre del matí en un servidor de debò, llegint aquesta complexitat a través de les finestres que el sistema mateix ens ofereix: /proc, el diari, els comptadors del nucli. Entre un punt i l'altre hi ha set mòduls, però en realitat hi ha una sola idea repetida: el sistema operatiu no és una caixa negra. És un programa, escrit per persones, que pren decisions comprensibles sobre recursos limitats, i que deixa rastre de totes elles. Aprendre a llegir aquest rastre és el que separa qui fa servir un ordinador de qui l'entén.

Ja saps fer-ho. La pròxima vegada que el telèfon soni a les tres de la matinada, no sabràs la resposta —ningú no la sap—, però sabràs com trobar-la: quantificar el símptoma, descartar amb dades, buscar la saturació i no la utilització, desconfiar de la primera explicació que encaixi i anotar-ho tot perquè a la persona següent li sigui més fàcil.

Gràcies per haver arribat fins aquí. Ara apaga això, obre un terminal i trenca alguna cosa.