La lliçó anterior va acabar amb una limitació clara de la shell: un guió solt no és un sistema. Algú ha d'arrencar meteo-api quan la màquina s'engega, esperar que /var/lib/meteora estigui muntat, reiniciar-lo si cau, executar l'agregador cada hora encara que el servidor estigués apagat a les 03:00, aplicar-los els límits i l'enfortiment del mòdul 5, i recollir-ne els registres. Aquest algú és el gestor de serveis: el procés amb PID 1 que el nucli arrenca al final de l'arrencada i que no mor fins que la màquina s'apaga.

Aquesta lliçó té dues meitats. A la primera seguim l'engegada de meteo-01 fase per fase, des que el microprogramari pren el control fins que apareix el PID 1, i aprenem què es pot observar i tocar a cada fase —perquè la meitat de les incidències greus d'arrencada es resolen sabent passar un paràmetre al nucli des de GRUB—. A la segona desmuntem systemd: el seu model d'unitats, l'anatomia completa de la unitat de meteo-api, les dependències, els temporitzadors que substitueixen cron, i el guió de diagnòstic de «el meu servei no arrenca», que és una de les coses que faràs més vegades a la teva vida professional.

El monitoratge de rendiment és la lliçó següent; aquí ens ocupem de què corre, quan i sota quines regles.

1. L'arrencada de meteo-01, fase a fase
2. Quin problema va resoldre systemd
3. El model d'unitats
4. Anatomia d'un fitxer d'unitat: meteo-api complet
5. Tipus de servei i com triar bé
6. Dependències davant d'ordre
7. Objectius i nivells d'execució
8. El maneig diari amb systemctl
9. Polítiques de reinici i el bucle que amaga una errada
10. Temporitzadors davant de cron
11. Activació per socket i per camí
12. Unitats d'usuari i loginctl
13. Anàlisi i depuració de l'arrencada
14. Aturada ordenada: SIGTERM, SIGKILL i TimeoutStopSec

Fase 1: microprogramari. En prémer el botó, la CPU comença a executar codi del microprogramari de la placa. Hi ha dos mons:

meteo-01 arrenca per UEFI. La seva ESP està muntada a /boot/efi i conté EFI/debian/grubx64.efi i el shimx64.efi signat per Microsoft que fa possible el Secure Boot: el microprogramari verifica la signatura de shim, shim la de GRUB, GRUB la del nucli i el nucli la dels mòduls. La cadena existeix per impedir un bootkit, codi maliciós que s'executa abans que el sistema operatiu i que per tant cap antivirus del sistema no pot veure. El seu preu pràctic és que un mòdul compilat a mà (per exemple un controlador propietari) no es carregarà sense signar-lo.

Què demostren. El nucli només crea /sys/firmware/efi si ha arrencat per UEFI: és la comprovació canònica. efibootmgr llegeix les variables NVRAM on el microprogramari desa l'ordre d'arrencada, i permet afegir o reordenar entrades sense entrar a la pantalla de configuració. mokutil informa de l'estat del Secure Boot.

Fase 2: gestor d'arrencada. GRUB llegeix /boot/grub/grub.cfg —fitxer generat, mai editat a mà: es produeix amb update-grub a partir de /etc/default/grub i /etc/grub.d/— i presenta el menú. Cada entrada indica un nucli, un initrd i una línia de paràmetres:

Prement e sobre l'entrada pots editar aquesta línia per a una sola arrencada, sense tocar el disc. És l'eina de rescat més important que existeix:

Fase 3: nucli i initramfs. GRUB carrega a memòria el nucli comprimit i l'initrd, i salta al nucli, que es descomprimeix, inicialitza la gestió de memòria del mòdul 2 i munta l'initramfs com a arrel temporal a la RAM.

Per què existeix l'initramfs? Per un problema de l'ou i la gallina. L'arrel real de meteo-01 és a /dev/md0, un RAID 1 sobre ext4. Per muntar-la cal el mòdul raid1 i el d'ext4… que són dins d'aquesta mateixa arrel. L'initramfs trenca el cercle: és un cpio comprimit amb els mòduls imprescindibles i un /init mínim que carrega els controladors, acobla el RAID, obre el LUKS si n'hi ha, activa els volums LVM i només llavors munta l'arrel real. Després executa switch_root, que substitueix l'arrel temporal per la real, allibera la RAM de l'initramfs i fa execve de /sbin/init —un enllaç a /lib/systemd/systemd— amb PID 1.

Què fan i per què importen. Si afegeixes un disc o canvies l'esquema d'emmagatzematge i oblides update-initramfs, la màquina arrencarà fins a l'initramfs i s'hi quedarà amb un prompt (initramfs) perquè no troba l'arrel: és un dels totxos més freqüents. I dmesg és la memòria intermèdia circular del nucli, on queda tot el que ha passat des de la primera instrucció: detecció de maquinari, errors de disc, l'OOM killer de 02-04, els missatges del RAID. -T tradueix les marques de temps relatives a dates llegibles.

Fase 4: PID 1. El PID 1 és especial per tres motius que venen de 02-01: no se li poden aplicar els senyals per defecte (el nucli ignora SIGTERM i SIGKILL cap a ell, perquè ningú no el pugui matar per accident), adopta els orfes i en recull els estats de sortida evitant els zombis, i si mor, el nucli entra en pànic. Tota la resta del sistema descendeix d'ell.

Abans de systemd, l'arrencada la governava SysV init: guions de shell a /etc/init.d/ que s'executaven per ordre alfabètic des de /etc/rc3.d/ (S01, S02, S03…), un darrere l'altre, cadascun arrencant el seu dimoni amb un start-stop-daemon. El model tenia cinc problemes greus:

Aquest últim punt és el més subestimat i connecta directament amb 06-02. Un guió SysV rastrejava el seu dimoni per un fitxer .pid; si el procés es dimonitzava malament, canviava de PID o llançava fills, el stop matava el PID equivocat i deixava processos orfes consumint recursos. systemd posa cada servei en un grup de control propi, així que la pertinença és una propietat del nucli, no una suposició: aturar el servei significa senyalar tot el cgroup, i els comptes de CPU, memòria i E/S del servei són exactes.

Què demostra. El camp CGroup de status llista tots els processos del servei, inclosos els que ell hagi llançat. Cap procés no se li escapa a systemd, perquè el cgroup l'assigna el nucli al fork i s'hereta.

Tot a systemd és una unitat: un fitxer de text en format INI que descriu alguna cosa que es gestiona. Els tipus que has de conèixer:

On viuen, per ordre de prioritat creixent:

Un fitxer a /etc/systemd/system/meteo-api.service substitueix del tot el del paquet. Gairebé mai no és el que vols: si el paquet millora la seva unitat, et quedes amb la vella. El correcte és un drop-in, un fragment que es fusiona amb l'original:

Què fan. systemctl edit obre un editor sobre /etc/systemd/system/meteo-api.service.d/override.conf, i en desar executa daemon-reload automàticament. systemctl cat és l'ordre que hauries de fer servir sempre abans de tocar res: mostra el fitxer d'origen i, a sota, cada drop-in amb el seu camí, de manera que veus la configuració efectiva i d'on surt cada directiva.

Un parany que cal conèixer: en un drop-in, les directives que accepten llistes (com ExecStart o Environment) s'acumulen. Per reemplaçar un ExecStart cal buidar-lo primer amb una línia ExecStart= sense valor i després posar-hi el nou.

Secció per secció:

• [Unit] descriu la unitat i les seves relacions. Description és el que apareix a systemctl status i als registres: escriu-la per a un humà mig adormit. After= fixa ordre, no dependència. RequiresMountsFor= és la manera correcta de dir «no arrenquis si aquests camins no estan muntats»: systemd dedueix sol les unitats .mount implicades, i és més robust que anomenar-les a mà, perquè el nom d'una unitat de muntatge es codifica d'una manera peculiar (/var/lib/meteora → var-lib-meteora.mount).
• [Service] defineix com s'executa. ExecStartPre corre abans i, si falla, el servei no arrenca: aquí reaprofitem el guió de verificació de 07-01 com a comprovació prèvia. ExecStart és el procés principal, sempre amb camí absolut (systemd no fa servir el PATH de la teva shell). ExecReload recarrega la configuració sense tallar les connexions; $MAINPID és una de les poques variables que systemd expandeix.
• El bloc d'enfortiment és el mòdul 5 fet directives. NoNewPrivileges posa el bit del nucli que impedeix guanyar privilegis per setuid, així que ni un binari setuid compromès no serviria d'escaló. AmbientCapabilities=CAP_NET_BIND_SERVICE és el que permet escoltar al port 443 sense ser root, i CapabilityBoundingSet fixa el sostre: encara que el procés volgués una altra capability, el nucli no l'hi concedeix. ProtectSystem=strict munta tot el sistema de fitxers en només lectura per al servei, i ReadWritePaths obre les tres excepcions necessàries. PrivateTmp li dona un /tmp propi en un namespace de muntatge, cosa que elimina d'arrel els atacs per fitxers temporals predictibles. SystemCallFilter=@system-service aplica un filtre seccomp que deixa passar el conjunt habitual d'un servei i bloqueja la resta retornant EPERM. UMask=0027 fixa els permisos de creació acordats per a Meteora.
• [Install] només es fa servir en fer enable. WantedBy=multi-user.target significa «quan s'habiliti, crea un enllaç a multi-user.target.wants/». Sense secció [Install], un servei no es pot habilitar: es pot arrencar a mà, però no arrenca sol. És un descuit freqüent.

Verifica sempre el que has escrit abans de confiar-hi:

Què aporten. verify detecta directives mal escrites i unitats referenciades inexistents, que altrament només donarien la cara en arrencar. security puntua de 0 (blindat) a 10 (exposat) avaluant desenes de directives d'aïllament, i llista una per una les que falten: és una llista de tasques d'enfortiment generada automàticament.

I la unitat de l'ingestor, més senzilla perquè no escolta en un port privilegiat:

El que és nou aquí. RuntimeDirectory=meteora fa que systemd creï /run/meteora amb el propietari i el mode indicats en arrencar i l'esborri en aturar-se: és la manera correcta de gestionar el directori on viu la FIFO /run/meteora/lectures.fifo, en lloc de crear-lo a mà en un guió. Nice=-5 dona a l'ingestor una mica més de prioritat de CPU (02-02) perquè perdre lectures entrants és irrecuperable, mentre que una consulta lenta de l'API només molesta.

Type= diu a systemd quan ha de considerar que el servei ja ha arrencat, cosa que governa quan poden arrencar els que en depenen.

L'errada típica, i és tan freqüent que es mereix detall: declarar Type=simple un programa que es dimonitza (fa fork, el pare surt, el fill continua). systemd veu que el procés que ha llançat ha acabat immediatament i, segons la política de reinici, o el dona per mort i el reinicia en bucle, o el dona per arrencat i correcte mentre el dimoni real corre sense supervisió. El símptoma és un status que diu active (exited) o un cicle de reinicis d'un servei que en realitat funciona. La solució no és barallar-se amb forking: és dir-li al programa que no es dimonitzi (gairebé tots tenen --foreground o -D) i fer servir Type=exec.

Hem triat Type=notify per a meteo-api per una raó concreta: el servei triga uns 8 segons a carregar l'índex i escalfar la memòria cau a /dev/shm/meteora-cache. Amb simple, systemd el donaria per llest a l'instant i qualsevol unitat que en depengui —o el balancejador que mira l'estat— actuaria sobre un servei que encara retorna errors. Amb notify, el programa crida sd_notify(0, "READY=1") quan de debò pot atendre, i systemd espera. WatchdogSec=30 hi afegeix el contrari: el servei ha d'enviar WATCHDOG=1 cada 30 segons o systemd el considera penjat i el reinicia, cosa que detecta bloqueigs interns que no maten el procés.

Aquesta és la distinció que causa més confusió, i és molt simple: són eixos independents.

La il·lustració crucial. Si escrius només Requires=var-lib-meteora.mount, systemd arrencarà el muntatge i el teu servei alhora, en paral·lel: pot ser que meteo-api intenti obrir /var/lib/meteora/lectures/2026-08-31.dat abans que el sistema de fitxers estigui muntat, i falli amb ENOENT. I si escrius només After=var-lib-meteora.mount, ordenes correctament però no demanes el muntatge: si ningú més no l'activa, el teu servei arrenca sense dades. Gairebé sempre necessites totes dues, i per això existeix RequiresMountsFor=: genera les dues de cop.

Un altre matís important: a l'aturada, l'ordre s'inverteix automàticament. After=network-online.target implica que en la parada meteo-api s'atura abans que la xarxa, que és justament el que vols per poder tancar les connexions netament.

I network-online.target es mereix una advertència: no significa «hi ha connectivitat a Internet», sinó «el gestor de xarxa declara que ha acabat de configurar les interfícies». Necessita que un servei com systemd-networkd-wait-online estigui habilitat; sense ell, l'objectiu s'assoleix immediatament i no garanteix res. Un servei robust reintenta la connexió en lloc de confiar en l'ordre d'arrencada.

Un objectiu (target) no fa res per si mateix: és un punt de sincronització que agrupa unitats. Substitueix els nivells d'execució de SysV:

Compte amb isolate. Atura totes les unitats que no formin part de l'objectiu destí: executat per error en producció, tomba els serveis. Com a diagnòstic previ, systemctl list-units --type=target mostra quins objectius estan actius ara mateix.

Camp a camp, que és on hi ha la informació:

enable davant de start és la confusió número u del principiant: start arrenca ara i no sobreviu al reinici; enable prepara l'arrencada futura però avui no arrenca res. I daemon-reload davant de reload: el primer diu a systemd que rellegeixi les unitats; el segon diu al servei que rellegeixi la seva configuració. Editar una unitat sense daemon-reload és un clàssic: systemd continua fent servir la versió vella i tu et tornes boig.

Els registres per unitat, amb el journalctl que ja coneixes de 05-04:

Per què això és millor que un fitxer de registre. Com que systemd és el pare del procés i captura el seu stdout i stderr, qualsevol cosa que el servei imprimeixi queda registrada, inclosos els missatges d'una errada en arrencar que mai no arribaria a escriure al seu propi fitxer. Cada entrada porta la unitat, el PID, l'UID i l'arrencada en què va passar, cosa que permet filtrar amb precisió. -b -1 és l'ordre que salva la investigació després d'un reinici inesperat.

Per a meteo-api fem servir on-failure: si algú l'atura expressament, ha de quedar-se aturat. Per a l'ingestor fem servir always, perquè no hi ha cap raó legítima perquè acabi.

El perill real és el bucle de reinici que amaga l'errada. Imagina que algú introdueix un error de sintaxi a /etc/meteora/meteora.conf: el servei arrenca, falla en 200 ms, systemd el reinicia, torna a fallar… A 200 ms per volta són 5 intents per segon, que omplen el diari, consumeixen CPU i —el pitjor— fan que un monitor que mostreja cada 30 segons vegi de vegades active i de vegades failed, amb la qual cosa l'alerta no s'acaba de disparar i ningú no investiga.

Per això hi ha el limitador d'arrencades i RestartSec:

Què aconsegueixen. Amb aquests valors, si el servei arrenca més de 5 vegades en 300 segons, systemd deixa d'intentar-ho i el marca failed amb el motiu start-limit-hit. Això converteix un bucle silenciós en un estat estable i visible, que sí que dispara l'alerta. RestartSec=5s evita a més el martelleig. Si l'errada és transitòria (una dependència que triga), 5 reintents separats per 5 segons donen prou marge. Després de corregir la causa cal executar systemctl reset-failed meteo-api.service per netejar el comptador abans de tornar a arrencar; oblidar-ho és un altre descuit habitual.

L'agregador s'ha d'executar cada hora. A systemd són dues unitats: la feina i el seu rellotge.

Directiva per directiva, amb el perquè:

• OnCalendar=hourly equival a *-*-* *:00:00. La sintaxi admet expressions com Mon..Fri 06:00, *-*-01 03:30 o daily. Comprova-la sempre abans de confiar-hi: systemd-analyze calendar 'Mon..Fri 06:00' --iterations=3 imprimeix les properes execucions reals.
• Persistent=true desa al disc la marca de l'última execució i, si la màquina estava apagada a l'hora prevista, executa la feina tan bon punt arrenca. És el que al món clàssic feia anacron, aquí amb una sola línia.
• RandomizedDelaySec=180 dispersa l'arrencada fins a 3 minuts a l'atzar. Amb una màquina tant se val, però amb cinquanta servidors que agreguen a les 03:00 en punt evita l'estampida que satura la cabina d'emmagatzematge compartida. AccuracySec=1min permet a més a systemd agrupar despertaments i estalviar energia; posa-ho a 1us només si de debò necessites precisió.
• IOSchedulingClass=idle i Nice=10 al servei fan que l'agregador cedeixi davant de meteo-api, tant al disc com a la CPU. Aquesta és exactament la mitigació que s'aplicarà al cas pràctic de 07-04.
• Type=oneshot amb TimeoutStartSec=900: la tasca acaba, no es queda corrent, i si al cap de 15 minuts no ha acabat es considera penjada.

Detall important: s'habilita el .timer, no el .service. Si habilitessis el servei, arrencaria també a cada inici del sistema. I per provar la tasca a mà s'arrenca el .service, que és la unitat que fa la feina.

Comparació amb cron:

Aquest últim punt és el que justifica conèixer crontab: continua sent omnipresent. Els cinc camps són minut, hora, dia del mes, mes i dia de la setmana (0 3 * * 1 = dilluns a les 03:00); crontab -e edita el de l'usuari i crontab -l el llista; a /etc/cron.d/ els fitxers porten un camp extra amb l'usuari. I una advertència que causa incidents: cron executa amb un PATH mínim (/usr/bin:/bin) i sense les variables de la teva sessió, que és exactament l'error de 07-01 sobre fitxers de configuració de shell. Fes servir camins absoluts sempre.

Com a regla: en sistemes amb systemd, temporitzador; i tot i així, mantén el flock dins del guió, perquè protegeix també davant d'una execució manual simultània.

L'activació per socket inverteix l'ordre habitual: systemd obre el punt d'escolta i només arrenca el servei quan arriba la primera connexió.

Què aconsegueix. El socket el crea systemd (amb privilegis) i el passa al servei com a descriptor de fitxer heretat, de manera que meteo-api ni tan sols necessita CAP_NET_BIND_SERVICE. A més, com que el socket existeix des de l'arrencada, les connexions que arribin mentre el servei es reinicia s'encuen al backlog en lloc de rebutjar-se: es poden fer desplegaments sense connexions perdudes. I les unitats que depenen del servei poden arrencar tan bon punt el socket està llest, no quan el procés està llest, cosa que paral·lelitza l'arrencada. És el mateix mecanisme que fa servir inetd des dels anys 80, però integrat amb la resta del model.

L'activació per camí vigila el sistema de fitxers:

Què aconsegueix. Tan bon punt apareix un fitxer que encaixa amb el patró, systemd arrenca processar-entrada.service. És l'alternativa correcta al bucle while true; do ls ...; sleep 10; done, perquè fa servir l'inotify del nucli: consum zero mentre no passa res i reacció immediata quan passa.

Cada usuari amb sessió té la seva pròpia instància de systemd, que gestiona unitats a ~/.config/systemd/user/ sense privilegis de root:

Per què importa. Per defecte, les unitats d'usuari moren en tancar l'última sessió: és el correcte per a un escriptori, però sorprèn en un servidor. enable-linger manté la instància viva. I loginctl és la finestra a systemd-logind, el component que gestiona sessions, seients i el pam_systemd que vas veure a 05-02. Regla pràctica: els serveis d'infraestructura, com els de Meteora, van sempre al gestor del sistema; les unitats d'usuari són per a tasques personals.

Com llegir-los, que és on falla tothom. blame ordena per durada, no per impacte: un servei que triga 6 segons però arrenca en paral·lel amb altres vint no retarda res. critical-chain sí que mostra el camí crític: @ és l'instant en què la unitat va començar i + el que va trigar, així que només reduint el que apareix en aquesta cadena s'escurça l'arrencada. A l'exemple, meteo-api sí que és al camí crític i el seu ExecStartPre de verificació és part d'aquests 6,8 segons: una decisió conscient de canviar arrencada ràpida per arrencada segura.

El guió de «el meu servei no arrenca», per ordre:

1. systemctl status meteo-api.service -l --no-pager — el motiu gairebé sempre és a les últimes línies. Mira l'Active: (failed, activating, inactive?) i el codi: status=203/EXEC és «no s'ha pogut executar el binari» (camí mal escrit, sense permís d'execució, shebang no vàlid); status=200/CHDIR és un WorkingDirectory inexistent; status=1 és el programa mateix sortint amb error.
2. journalctl -u meteo-api.service -n 100 --no-pager — el missatge real del programa. Si és buit, l'errada és anterior al programa.
3. systemctl cat meteo-api.service — comprova que la unitat efectiva és la que et penses, amb els seus drop-ins. Has fet daemon-reload?
4. systemd-analyze verify /etc/systemd/system/meteo-api.service — sintaxi i referències.
5. Executa l'ordre a mà, com l'usuari del servei: sudo -u meteora /usr/local/bin/meteo-api --config /etc/meteora/meteora.conf. Si a mà funciona i com a servei no, la diferència és a l'entorn: PATH, directori de treball, variables, o l'enfortiment.
6. Sospita de l'enfortiment, que és la causa moderna més freqüent. Comenta temporalment ProtectSystem=strict o SystemCallFilter= en un drop-in i prova-ho. Si amb això arrenca, ja saps quina directiva has d'afinar; busca-ho amb journalctl -k | grep -i seccomp o _AUDIT_FIELD_SYSCALL.
7. Comprova permisos i SELinux/AppArmor: namei -l /var/lib/meteora/lectures recorre el camí sencer mostrant el propietari i el mode de cada component, i dmesg | grep -i denied delata el control d'accés obligatori de 05-01.
8. Dependències: systemctl list-dependencies --failed i systemctl show -p After -p Requires.

Quan executes systemctl stop meteo-api.service, systemd segueix una seqüència estricta:

1. Envia SIGTERM al procés principal (o executa ExecStop si existeix).
2. Espera fins a TimeoutStopSec (30 s a la nostra unitat).
3. Si no ha acabat, envia SIGKILL a tots els processos del cgroup.

La diferència entre els dos senyals és la de sempre (03-03): SIGTERM és una petició educada que el programa pot capturar per acabar les peticions en curs, bolcar la memòria cau de /dev/shm/meteora-cache, fer fsync del que queda pendent i tancar; SIGKILL l'executa el nucli i no es pot capturar, així que el procés desapareix a mitges del que estigués fent.

Per què el valor de TimeoutStopSec importa de debò. Si és massa curt, un meteo-api que està acabant d'escriure un bloc rep SIGKILL a mitges i deixa un fitxer de lectures truncat —exactament el cas que detecta la comprovació mida % 24 != 0 del guió de 07-01—. Si és massa llarg, un reinici del sistema es queda penjat minuts esperant un procés que no respondrà mai. El valor correcte és el pitjor cas raonable de tancament net, més un marge: per a meteo-api, amb fins a 2 GB de memòria cau per bolcar, 30 segons.

A l'apagada completa (systemctl poweroff), systemd atura les unitats en ordre invers al d'arrencada, desmunta els sistemes de fitxers, sincronitza el disc i apaga. Si algun cop veus el missatge A stop job is running for ... (1min 30s / 2min) durant una apagada eterna, estàs veient exactament aquest mecanisme: una unitat que no respon a SIGTERM i esgota el seu temporitzador. journalctl -b -1 -p warning et dirà quina va ser.

Consells: fes servir sempre systemctl cat abans de modificar res, perquè mostra la configuració efectiva; afegeix Documentation= a les teves unitats perquè qui et rellevi sàpiga on mirar; executa systemd-analyze security sobre cada servei nou i tracta-ho com una llista de tasques; i prova els reinicis de debò: un servidor que porta 400 dies engegat i que no s'ha reiniciat mai amaga, gairebé amb tota seguretat, un servei que no està habilitat.

Converteix el guió verificar-lectures.sh de 07-01 en un servei amb temporitzador que s'executi cada dia a les 06:15, recuperi l'execució si la màquina estava apagada, corri com a meteora sense més privilegis dels necessaris, no pugui escriure enlloc i es doni per penjat al cap de 10 minuts. Escriu les dues unitats i les ordres per activar-les i provar-les.

Després d'un canvi, meteo-api no arrenca. systemctl status mostra:

Enumera, per ordre, les comprovacions que faries i quina causa confirmaria cadascuna.

Un company defineix l'ingestor amb Restart=always i RestartSec=0, sense límit d'arrencades. Un error de configuració fa que falli en arrencar. Descriu què passa a la màquina en els 60 segons següents, per què el monitoratge podria no avisar, i quines tres directives hi afegiries.

Solució 1

Punts clau. ProtectSystem=strict sense ReadWritePaths deixa tot el sistema en només lectura, que és justament el que demana l'enunciat: el verificador només llegeix (el seu directori temporal el cobreix PrivateTmp). CapabilityBoundingSet= buit elimina totes les capabilities, perquè un guió de comprovació no en necessita cap. TimeoutStartSec=600 dona els 10 minuts demanats, i com que és Type=oneshot systemd sap que la unitat ha acabat quan el procés surt. SuccessExitStatus=0 1 és el detall fi: el nostre guió retorna 1 quan hi ha advertiments, i no volem que això marqui la unitat com a failed; el 3 (crític) sí que ho ha de fer. I Persistent=true cobreix el requisit de recuperar l'execució perduda.

Solució 2

status=203/EXEC significa que l'execve ha fallat: systemd no ha arribat a executar res, així que el diari del servei estarà buit i el problema és del binari o del seu entorn, no del programa. Comprovacions, de més a menys probable:

1. ls -l /usr/local/bin/meteo-api — existeix? És el camí exacte, sense errada? Un desplegament que va deixar el binari a /usr/local/sbin dona aquest error.
2. stat -c '%A %U %G' /usr/local/bin/meteo-api — té bit d'execució? Un scp o un git checkout mal fet el pot treure.
3. namei -l /usr/local/bin/meteo-api — l'usuari meteora pot travessar tots els directoris del camí? N'hi ha prou que un directori intermedi perdi el bit x perquè falli.
4. head -c2 /usr/local/bin/meteo-api i file — si és un guió, el seu shebang apunta a un intèrpret que existeix? Un #!/usr/bin/env python3 sense python3 instal·lat produeix exactament 203/EXEC.
5. ldd /usr/local/bin/meteo-api | grep 'not found' — falta alguna biblioteca compartida?
6. mount | grep ' /usr/local ' — està muntat amb noexec? És rar però passa, sobretot en particions separades enfortides.
7. systemctl cat meteo-api.service — hi ha un drop-in recent que hagi canviat ExecStart o hi hagi afegit un WorkingDirectory inexistent (això donaria 200/CHDIR)?
8. Prova directa: sudo -u meteora /usr/local/bin/meteo-api --config /etc/meteora/meteora.conf. Si funciona a mà, revisa l'enfortiment, començant per SystemCallFilter i ProtectSystem.

Solució 3

Què passa. Amb RestartSec=0 i sense límit, el cicle arrencar-fallar es repeteix tan de pressa com el sistema pugui fer fork+execve: si l'errada triga 50 ms a manifestar-se, són unes 20 execucions per segon, és a dir al voltant de 1.200 al primer minut. Conseqüències: consum continu de CPU en creació de processos, milers d'entrades al diari que poden arribar als límits de taxa de journald (RateLimitBurst) i fer que es descartin missatges —perdent justament els que expliquen l'errada—, i pressió d'E/S sobre /var/log.

Per què el monitoratge podria no avisar. Una comprovació que executa systemctl is-active ingestor cada 30 segons té una probabilitat alta de caure justament en una finestra en què el servei està activating o active, perquè l'estat oscil·la desenes de vegades per segon. El resultat és una alerta intermitent («flapping») que molts sistemes suprimeixen per sorollosa, o directament una sèrie de comprovacions correctes. El servei no arriba mai a un estat estable d'errada, que és el que les alertes saben detectar.

Les tres directives:

Amb això, el pitjor cas són 5 reintents en 25 segons i després un estat failed estable, que dispara l'alerta a la primera comprovació i deixa el diari llegible. Hi afegiria a més Restart=on-failure en lloc d'always si hi hagués algun motiu legítim per aturar el servei, i una alerta específica sobre la sortida de systemctl list-units --failed, que és el senyal més barat i fiable que alguna cosa va malament a la màquina.

Has seguit l'engegada de meteo-01 sencera: el microprogramari UEFI llegint l'ESP i verificant signatures amb Secure Boot; GRUB presentant el menú, la línia de paràmetres del qual és l'eina de rescat més valuosa que tens; el nucli i l'initramfs, que existeix per trencar el cercle de necessitar els mòduls de RAID i ext4 que viuen dins de l'arrel que encara no pot muntar; el switch_root i, per fi, el PID 1, que no es pot matar, adopta orfes i la mort del qual provoca un pànic.

I has desmuntat systemd, que va resoldre cinc mancances reals dels guions seqüencials de SysV: paral·lelisme, dependències declarades, activació sota demanda, supervisió i —la més subestimada— un cgroup per servei, que converteix «els processos d'aquest servei» en un fet del nucli i no en una suposició d'un fitxer .pid. Sobre aquest model has escrit la unitat completa de meteo-api, on cada bloc té la seva raó: Type=notify perquè triga 8 segons a estar realment llest, AmbientCapabilities=CAP_NET_BIND_SERVICE per escoltar al 443 sense ser root, ProtectSystem=strict amb tres ReadWritePaths, un filtre seccomp, i els límits de memòria i E/S del cgroup.

I has vist els mecanismes que es fan servir a diari: la distinció entre dependència i ordre, que explica la meitat de les arrencades trencades; enable davant de start i daemon-reload davant de reload; status llegit camp a camp; el bucle de reinici que amaga una errada i les tres directives que el converteixen en un estat visible; els temporitzadors amb Persistent=true i RandomizedDelaySec davant de cron; l'activació per socket, que permet reiniciar sense perdre connexions; critical-chain davant de blame; el guió de vuit passos per a «no arrenca»; i la seqüència SIGTERM → TimeoutStopSec → SIGKILL, el valor mal triat de la qual produeix exactament els fitxers truncats que detectàvem a la lliçó anterior.

Amb això, meteo-01 arrenca sol, es recupera sol i executa les seves tasques a la seva hora. Però un sistema que arrenca correctament pot funcionar malament. El servei està active (running), el temporitzador es dispara puntualment, no hi ha cap unitat en failed… i tot i així els usuaris es queixen que l'API va lenta. Cap de les eines d'aquesta lliçó no respon al «per què?»: per a això calen un mètode i uns quants números.

És el tema següent: Monitoratge i Diagnòstic de Rendiment, on aprendràs què has de mirar en els primers 60 segons d'una incidència i com passar d'un símptoma vague a una causa concreta.